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1.0  SCOPE 

1.1  Identification 

The  software  that  has  been  developed  as  part  of  the  Synthetic  Terrain  Imagery  for 
Helmet-Mounted  Display  program  is  written  in  C  and  is  designed  to  execute  on  a  Silicon 
Graphics  VGX  Workstation.  This  software  was  developed  for  purposes  of  evaluating  the 
utility  of  synthetically  derived  representations  of  the  local  terrain  presented  on  a  helmet- 
mounted  display. 

1.2  System  Overview 

The  software  samples  data  from  a  preprocessed  database  created  from  the  U.S.  Defense 
Mapping  Agency’s  Digital  Terrain  Elevation  Data  (DTED)  database  and  renders,  in 
perspective  view,  the  visual  scene.  An  NTSC  video  signal  drives  a  helmet-mounted 
display. 


1.2.1  Program  Overview 

The  Synthetic  Terrain  Imagery  for  Helmet  Mounted  Display  program  was  written 
to  present  digital  terrain  elevation  data  to  pilots  in  severd  different  formats  on  an 
HMD.  The  program  can  be  run  standalone,  in  which  case  it  behaves  like  the 
“flight”  program  that  is  provided  by  Silicon  Graphics,  or  it  can  be  integrated  into 
a  simulation  environment  which  communicates  over  the  ethemet. 

1.2.2  Program  Flow 

See  section  3.1.2  for  a  flow  diagram  of  the  program. 

1.2.3  Interfaces 

1.2.3. 1  Inputs 

The  STI  program  can  be  compiled  for  networked  operation,  where  it  gets 
all  inputs  from  other  simulations,  or  it  can  be  compiled  for  standalone 
operation  by  including  the  -D  STANDALONE  flag  on  the  compile  line  in 
the  makefile. 

1.2.3. 1.1  Networked 

When  compiled  normally  the  STI  program  accesses  terrain  data  in 
global  memory  that  has  been  load^  by  another  program.  The  SH 
program  opens  the  terrain  data  and  sets  a  pointer  to  the  global  data 
structure  in  the  routine  attach_tdb  which  is  defined  in  the  file 
dma.c  and  called  by  the  main  program  sti.c 

The  position  and  other  data  for  own-ship  is  also  pulled  out  of 
global  memory.  (Actually  the  data  comes  in  over  the  Ethemet  and 
is  put  into  global  memory  by  another  program.  From  the  STI  point 
of  view  the  data  comes  from  global  memory.)  The  own-ship  data 
is  pulled  from  global  memory  and  processed  by  the  routine 
control.c.  At  this  point  the  own-ship  location  coordinates  are 
converted  from  degrees  to  feet. 
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1.2.3.1.2 


Standalone 


When  the  -DSTAND ALONE  flag  is  included  on  the  compile  line 
in  the  STI  makefile,  the  program  is  compiled  to  run  self  contained 
without  any  other  programs  running.  In  this  situation  the  path  to  a 
terrain  data  file  must  be  passed  as  a  parameter  on  the  command 
line.  Own-ship  data  is  calculated  internally  and  the  keyboard  user 
interface  is  active  allowing  the  user  to  control  the  own-ship  with 
the  mouse  and  keyboard. 

1. 2.3.2  Output 

The  video  output  of  the  STI  program  can  take  several  different  forms 
depending  on  the  command  line  options  specified  at  start  up.  If  no 
command  line  options  are  given,  the  video  will  be  full  screen  60  HZ  high 
resolution.  If  the  -s  (for  small  window)  option  is  given,  the  a  window  Ae 
size  of  an  NTSC  signal  will  be  opened  in  the  lower  left  comer  of  the  high 
resolution  monitor.  If  the  -n  (ntsc  mode)  option  is  given,  the  video  is 
changed  to  RS 170,  and  a  full  sized  window  will  be  displayed.  This  is  the 
video  format  needed  for  most  HMDs. 

1.2.4  Rendering  Routines  (see  section  4. 1.1. 3-D  for  detailed  algorithms) 

The  STI  program  will  currently  render  the  terrain  in  any  one  of  the  following 
formats  (subroutines  to  render  the  formats  in  parenthesis): 

Post  tops.  In  this  format  the  terrain  is  rendered  by  drawing  a  point  at  the  top  of 
each  post  which  is  in  the  view  volume,  (drawpoints  (pg.  A-24)) 
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Square  post  tops  (Tiles).  This  format  will  draw  a  square  of  variable  size,  as 
prescribed  by  the  global  variable  reclen,  at  the  top  of  each  post  within  the  view 
volume.  The  elevation  data  is  bilinearly  interpolated  to  obtain  the  z- value  for 
each  comer  of  the  square,  so  the  slope  of  the  square  is  oriented  to  the  terrain, 
(drawsquares  (pg.  A-27)) 


Wireframe  mesh.  This  format  is  rendered  as  a  set  of  grids  which  are  fixed  to  the 
terrain.  It  takes  two  passes  through  the  elevation  data  to  render  the  mesh.  On  the 
first  pass,  it  draws  all  lines  running  east-west,  and  the  second  pass  draws  the  lines 
running  north-south,  (drawmesh  (pg.  A-22)) 
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Hybrid  mesh  and  tiles.  A  wireframe  mesh  (see  above)  is  first  drawn,  and  then 
tiles  are  drawn  in  the  center  of  the  squares  formed  by  the  mesh.  The  tiles  are 
drawn  by  the  same  routine  which  draws  the  square  post  tops  (see  above),  but 
instead  of  putting  the  tiles  at  the  post  tops,  they  are  offset  to  fill  the  gaps  formed 
by  the  mesh,  (drawmesh  (pg.  A-22)  &  drawsquares  (pg.  A-27)) 
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Hybrid  Mesh  and  Tiles 

Emergent  detail  #1.  The  emergent  detail  formats  are  an  attempt  to  provide  more 
detail  as  the  pilot  approaches  the  ground.  When  the  height  above  ground  level 
(AGL)  is  greater  than  2000  feet,  a  wireframe  mesh  is  drawn,  when  agl  is  between 
750  feet  and  2000  feet  a  variant  of  the  hybrid  mentioned  above  is  us^  with  points 
instead  of  squares  in  the  gaps  formed  by  the  mesh.  When  AGL  is  below  750  feet, 
the  hybrid  format  is  drawn,  (drawmesh  (pg.  A-22),  drawsquares  (pg.  A-27),  and 
drawpoints  (pg.  A-24)) 

Emergent  detail  #2.  Above  2000  feet  agl.  Post  tops  are  rendered.  Between  750 
and  2000,  the  mesh  is  drawn.  Below  750  feet,  the  hybrid  is  drawn,  (drawmesh 
(pg.  A-22),  drawsquares  (pg.  A-27),  and  drawpoints  (pg.  A-24)) 

Optical  expansion  gradient.  In  this  format,  the  terrain  is  rendered  as  lines  running 
parallel  to  the  motion  of  the  aircraft.  The  gradient  is  fixed  to  the  aircraft,  so  the 
elevation  data  must  be  bi-linearly  interpolated  to  find  points  along  each  line  that  is 
to  be  drawn,  (drawgradient  (pg.  A- 18)) 
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Optical  Expansion  Gradient 
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Lighted  polygons.  The  terrain  is  rendered  as  lighted  shaded  polygons  using  the 
lighting  utilities  of  the  Silicon  Graphics’  graphics  library.  The  color  shading 
scheme  goes  from  blue  in  the  low  regions  to  green  in  the  middle  regions  to  red  in 
the  upper  regions  (defined  in  the  subroutine  initmap  (pg.  A-40)).  This  is  the  only 
format  that  uses  the  surface  normals  of  the  elevation  posts.  A  representation  of 
this  format  is  not  shown  in  this  document  because  of  the  reliance  on  color  for 
meaningful  perception  of  depth  to  occur,  (drawpolys  (pg.  A-25)) 

Shaded  polygons.  This  format  displays  the  terrain  as  Gouraud  shaded  polygons. 
There  is  no  lighting  used.  See  the  Description  for  Lighted  polygons  for  the  color 
scheme.  A  representation  of  this  format  is  not  shown  in  this  document  because  of 
the  reliance  on  color  for  meaningful  perception  of  depth  to  occur,  (drawpolys  (pg. 
A-25)) 

Orthogonal  format.  In  this  head  referenced  format,  ridgelines  are  drawn  at  1.5, 

3.0, 4.5  and  6.0  NM  intervals.  Four  angular  projection  lines  are  then  drawn  at 
+  20®  fixjm  the  line  of  sight  of  the  HMD.  To  facilitate  drawing  time,  one  set  of 
point  arrays  is  drawn  while  a  second  set  is  being  updated.  (Draw_dma_grid  (pg. 
A-16)) 


BOHMO-GD-TOI 

Orthogonal  Format 

Ridgelines  and  Post  tops.  This  format  renders  the  terrain  as  ridgelines  plus  the 
post  top  format  to  add  detail,  (drawpoints  (pg.  A-24)  and  Draw_dma_ridge  (pg. 
A-17)) 
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Ridgelines  and  gradient.  This  format  is  similar  to  the  orthogonal  format.  It  draws 
ridgelines  with  the  optical  expansion  gradient.  The  difference  between  this  and 
the  orthogonal  format  is  that  the  spacing  may  be  varied  between  the  gradient  lines 
by  changing  the  global  variable  slap,  while  the  orthogonal  format  always  has  a 
fixed  spacing,  (drawgradient  (pg.  A-18)  and  Draw_(hiia_ridge  (pg.  A-17)) 
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Ridgelines  and  Gradient 

1.2.5  Data 

The  elevation  data  used  for  the  simulation  is  DMA  level  1  DTED  pre-processed 
into  Lockheed’s  format.  (Lockheed  preprocesses  the  “raw”  DMA  array  into  128- 
by-128  sample  tile  to  be  used  in  a  larger  gaming  area.)  The  format  is  designed  to 
create  a  regularly  structured  database,  scded  in  feet  to  improve  the  efficiency  of 
the  rendering  routines.  See  section  4. 1.1.2-F  for  a  more  detailed  description  of  the 
format. 

1.2.6  Multiple  Processes 

The  STI  program  spawns  two  processes,  both  of  which  are  spawned  from  the 
main  function  (defined  in  STI.c).  The  first  is  loadtile,  which  reads  the  elevation 
data  from  the  disk  and  places  it  in  the  appropriate  data  structure.  It  communicates 
with  its  parent  process  through  the  mpflag  in  the  Tile_t  structure.  The  other  is 
gridupdate,  which  calculates  the  lines  for  the  orthogonal  and  ridgeline  formats.  It 
^so  communicates  with  the  parent  process  through  the  same  flag  in  the  Tile_t 
structure. 

See  section  4. 1.1. 2-1.2  for  a  description  of  the  Tile_t  structure. 

1.3  Document  Overview 

The  purpose  of  this  document  is  to  describe  the  software  program  (STI). 

This  document  is  organized  in  accordance  with  Data  Information  specification  DI- 
MCCR-80012A. 
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2.0  REFERENCED  DOCUMENTS 


Appendix  A  is  a  complete  listing  of  the  headers  for  the  subroutines  for  the  STI  software 
program.  The  first  two  pages  of  Appendix  A  show  the  keyboard  control  commands  for 
the  STI  program  when  it  is  run  “stand  alone”  on  a  Silicon  Graphics  workstation. 

A  “Concept  Paper”  detailing  the  technical  efforts  that  are  part  of  the  Synthetic  Terrain 
Imagery  for  Helmet-Mounted  Display  program  aids  the  reader  in  understanding  this 
software  design  document.  The  Concept  Paper  is  included  as  Appendix  B  in  this 
document. 

3.0  PRELIMINARY  DESIGN 
3.1  CSCI  Oyeryiew 

The  following  sections  outline  the  organizational  structure  and  data  flow  for  the  software 
described  in  Ais  document 
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3.1.1  CS Cl  Architecture 

The  following  chart  outlines  the  organizational  structure  of  the  software. 


cnv_angl0  colour  getolov  colour  colour  getolev  olevcolor  colour 


3. 1.2  Systems  States  and  Modes 

The  next  illustrations  provide  an  overview  of  the  loop  structure  for  the  executable 
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3.1.3  Processing  Time  Allocation 

The  design  goal  for  the  STI  program  is  to  update  the  image  at  a  minimum  30  Hz 
rate  (less  than  33  msec  frame  time).  However,  to  facilitate  cases  where  the 
available  throughput  of  the  Silicon  Graphics  workstation  is  unable  to  render  the 
necessary  number  of  polygons/lines  (dependent  on  the  size  of  the  projected  view 
volume  onto  the  terrain  and  the  sample  size  of  the  terrain)  this  rate  will  decrease. 
In  less  demanding  conditions,  the  rate  will  increase  to  greater  than  30  Hz  thereby 
reducing  the  latency  of  the  image  of  the  video  frame  buffer.  Nominally,  the  SH 
routines  will  meet  tiiis  requirement  but  there  are  conditions  where  the  effective 
throughput  is  insufficient.  Optimizing  the  clipping  routines  and  judicious 
sampling  of  the  database  as  controlled  by  altitude  and  grazing  angle  serve  to 
mitigate  these  effects. 


4.0  DETAILED  DESIGN 

4. 1 . 1 . 1  Design  specifications/constraints 

The  simulation  runs  on  a  Silicon  Graphics  4D  series  computer.  There  are 
multiple  processes  running,  so  there  should  be  multiple  CPUs,  otherwise 
there  will  be  a  performance  penalty.  The  memory  requirement  is  32 
Megabytes  of  memory.  Again,  the  simulation  will  run  with  less  memory, 
but  there  will  be  a  significant  performance  penalty. 

4.1.1.2  Design 

The  simulation  is  written  in  the  C  programming  language.  The  make 
utility  is  used  to  compile  the  simulation.  The  simulation  can  be  compiled 
for  standalone  operation  by  including  the  _DSTAND ALONE  flag  in  the 
makefile. 

4.1.1 .2- A.  Inpul/output  data  elements 

The  data  inputs  to  the  STI  simulation  are  specified  in  the  targets.h  and 
terrain.h  include  files.  This  information  is  copied  from  global  memory 
during  each  iteration  within  controLc.  Additional  data  is  computed  by  the 
routine  Angle_computations  called  within  controLc 
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Infonnation  specific  to  the  terrain  data  is  described  in  the  include  file 
terrain_db.h  written  by  Lockheed.  This  information  is  pulled  from  global 
memory  and  put  into  local  variables  by  the  routine  fillglobals  called  from 
sti.c. 


Global  variables 


float  SWLATITUDE; 

float  SWLONGITUDE; 

int  LATRES; 
int  LNGRES; 
double  LATO; 

double  LNGO; 

intxb; 

int  xe; 
int  yb; 
int  ye; 
int  hidden; 
int  skip; 

int  depth; 
int  fat; 

float  position[4]; 

float  heading; 
float  dist; 
float  aspect; 
float  fov; 
float  reclen; 

FILE  *dmafp; 

Tile_t  tiles[2]; 

Tile_t  *tile; 


/*  Latitude  of  SW  comer  of  database 
(in  degrees)  */ 

/*  Longitude  of  SW  comer  of  database 
(in  degrees)  */ 

/*  Number  of  points  per  degree  Latitude  */ 

/*  Number  of  points  per  degree  Longitude  */ 
/*  Latitude  of  SW  comer  of  database 
(in  feet)  */ 

/*  Longitude  of  SW  comer  of  database 
(in  feet)  */ 

/*  beginning  x  extent  of  tile  to  be  drawn 
index  into  elev.  array*/ 

/*  ending  x  extent  of  tile  to  be  drawn  */ 

/*  beginning  y  extent  of  tile  to  be  drawn  */ 

/*  ending  y  extent  of  tile  to  be  drawn  */ 

/*  hidden  point/line  removal  on/off  */ 

/*  distance  (in  posts)  between  displayed 
posts  */ 

/*  depth-cueing  on/off  */ 

/*  lines  are  fat/skinny  */ 

/*  ownship  position,  x,  y,  z,  x-east,  y-north, 
z-up  (in  feet)*/ 

/*  compass  heading  of  ownship  */ 

/*  distance  we  can  see  (in  feet)  */ 

/*  aspect  ratio  (x/y)  of  the  display  */ 

/*  field  of  view  in  the  y  direction  (degrees)*/ 
/*  length  of  the  side  of  polygonal  posts 
(feet)*/ 

/*  file  pointer  to  the  terrain  file  */ 

/*  elevation  as  it  is  read  from  disk 
(ref.  4. 1.1. 2-1-2)*/ 

/*  pointer  to  the  current  buffer  of  tiles  */ 

/*The  field  of  view  of  helmet  in  x  and  y  for 
displaying  symbology*/ 


float  hmd_fov_xl,  hmd_fov_yl,  hmd_fov_x2,  hmd_fov_y2; 


/*  declaration  of  the  point  arrays  for  the  orthogonal  and  ridgeline  algs.  */ 
float  h[2][5][300][3],  vr[2][4][300][3],  vl[2][4][300][3]; 

/*  the  number  of  points  in  each  of  the  above  arrays.  */ 
int  nph[2][5],  npvr[2][4].  npvl[2][4]; 


/*  use  a  double  buffered  system  for  the  DMA  grids.  While  [toggle] 
is  being  set  up,  [Itoggle]  is  being  drawn.  */ 
int  toggle; 
int  format; 
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/*  index  which  points  to  the  current  buffer  being  manipulated 
by  concurrent  processes.  */ 
int  mpbuf; 

struct  target_type  os;  /*  ownship  data  structure  (ref.  4. 1.1. 2-1.4)*/ 

FILE  *tfile;  /*  output  timing  file  */ 

long  fgmode;  /*  the  fog  mode  currently  being  used  */ 

float  fgparms[5];  /*  parameters  for  the  fogvertex  call  */ 

Formal  parameters  (see  appendix  A  for  parameters  to  subroutines) 

4.1.1 .2-B.  Local  data  elements 


Local  data  (see  software  listing) 

4.1.1 .2-C.  Interrupts  and  signals 

The  interrupts  and  signals  to  control  the  simulation  are  commands 
received  over  the  ethemet,  and  operator  inputs  via  the  keyboard. 


operator  key  commands: 


ESC  KEY: 
FI  KEY: 
F2KEY: 
F3KEY: 
F4KEY: 


F5KEY: 


F6KEY: 


F7KEY: 
F8  KEY: 
F9KEY: 
FIOKEY 
FI  1  KEY 
F12KEY 
I/O  KEY: 


UP/DOWN  ARROW: 

CKEY: 

QKEY: 

HKEY: 

M/LKEY: 

B/DKEY: 

TKEY: 

VKEY: 


exit 

set  format  to  point  post  tops 
set  format  to  polygonal  post  tops 
set  format  to  wireframe  mesh 
set  format  to  wireframe  mesh  with 
polygonal  posts  in  the  center  of  the  mesh 
set  format  to  emergent  detail,  grid  >  2000, 
grid  plus  points  >  750  &&  <  2000,  grid 
plus  square  posts  <750 
set  format  to  emergent  detail,  points  >  2000, 
grid  >  750  &&  <  2000,  grid  plus  square 
posts  <  750 

set  format  to  Optical  Expansion  Gradient 
set  format  to  Lighted  Polygons 
set  format  to  Elevation  shaded  Polygons 
set  format  to  CD’s  orthogonal  format 
set  format  to  ridgelines  +  post  tops 
set  format  to  lidgelines  +  gradient 
increase/decrease  the  spacing  between  posts, 
spacing  can  take  on  the  values  of  100, 200, 
400  or  800  meters. 

increase/decrease  the  side  length  of  the 
polygonal  posts 
toggle  depth  cueing 
toggle  single  or  double  width  lines 
toggle  hidden  point/line  removal 
increase/decrease  the  distance  to  local  horizon 
brighten/darken  the  STI 
toggle  display  of  terrain  on/off 
toggle  variable  local  horizon  on/off 
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The  following  key  commands  are  for  STANDALONE  operation  only: 


S/A  KEY: 

HOME  KEY: 

L/RT  MOUSE: 
MIDDLE  MOUSE: 


increase/decrease  velocity 
return  simulation  to  original  position 
slew  the  helmet 
reset  helmet  to  0 


MOUSE  POSITION: 

MOUSE-X:  roll  of  the  aircraft 

MOUSE- Y :  pitch  of  the  aircraft 

to  turn,  roll  the  aircraft  about  90  degrees, 
and  then  pull  back  on  the  mouse. 

4.1.L2-D.  Algorithms 


Coordinate  system.  The  default  coordinate  system  used  in  the  STI  program 
assumes  a  flat  earth  with  the  x-axis  running  east-west,  x  is  positive  east. 
The  y-axis  runs  north-south,  with  north  being  positive.  Z  is  the  elevation 
and  is  positive  up.  All  x,y,z  coordinates  are  specified  in  feet. 


The  coordinate  transform  functions  used  in  the  STI  simulation  assume  a 
flat  earth  model.  The  functions  can  be  changed  to  use  a  universal  trans- 
Mercator  model  by  including  the  line:  #define  UTM  at  the  beginning  of 
the  routines:  loadtile,  memory,  and  control.  This  model  is  more  accurate 
at  the  expense  of  a  noticeable  decrease  in  update  rate. 

Reading  elevation  data  from  disk.  The  routines  loadtile  and 
managememory  coordinate  to  copy  elevation  data  from  global  memory 
into  local  memory  when  needed.  These  routine  also  calculate  additional 
features  that  will  be  used  when  drawing  the  data.  If  the  UTM  flag  is 
defined,  the  x,y  locations  for  each  point  are  computed  using  a  the 
universal  trans-Mercator  projection. 

Managememory.  The  routine  managememory  (pg.  A-46)  does  the 
memory  management  job  for  the  SH  program.  As  input  it  takes  the 
current  position  in  feet,  converts  it  into  file  blocks  (according  to  CD's 
format),  and  determines  if  a  new  tile  must  be  loaded  into  memory.  If  a 
new  tile  needs  to  be  loaded,  it  calls  the  loadtile  process  indirectly  through 
the  mpflag,  blkrow,  and  blkcol  fields  of  the  current  buffer  of  the  tiles 
array. 

This  routine  always  looks  at  the  same  buffer  of  the  tiles  array  as  loadtile, 
so  it  can  tell  loadtile  to  start  reading  in  a  new  tile,  and  also  to  catch  the 
signal  from  loadtile  that  it  (loadtile)  has  complete  the  load.  On  the  first 
invocation,  managememory  must  call  loadtile  and  wait  until  loadtile  has 
finished  so  the  global  pointer  tile  can  point  to  some  real  data.  After  the 
first  call,  we  never  wait  for  loadtile.  We  simply  check  to  see  if  it  has 
finished  with  the  current  load,  and  if  it  has  do  two  things:  first  make  sure 
tile  points  to  the  current  buffer  (which  contains  the  most  recently  loaded 
data),  and  second  check  to  see  if  we  need  to  start  loading  another  tile.  If 
another  tile  is  needed,  “swap”  buffers  and  give  loadtile  the  appropriate 
parameters  in  the  tiles  array.  Let  loadtile  do  its  thing  while 
managememory  returns  control  to  the  calling  routine.  If  loadtile  wasn't 
finished  with  it's  current  tile,  simply  return  control  to  the  calling  routine. 
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Loadtile.  Loadtile  was  written  to  be  spawned  as  a  separate  process  with 
the  sproc  call.  There  are  no  formal  parameters,  but  it  communicates  with 
the  parent  process  through  several  fields  of  the  array  tiles. 

Loadtile  loads  the  appropriate  tile,  block  by  block  (calling  loadblock  (pg. 
A-42)),  into  memory,  sets  the  appropriate  fields  of  the  structure,  and 
computes  the  surface  normals  of  the  terrain  at  each  elevation  post. 

A  “double  buffered”  approach  has  been  adopted  to  avoid  the  problems  of 
multiple  processes  concurrently  accessing  and  modifying  the  same 
memory  locations.  The  parent  process  will  use  one  buffer  while  loadtile 
will  modify  the  other  buffer  until  processing  is  completed,  at  which  time 
the  buffers  are  “swapped”. 

Loadtile  will  wait  until  the  mpflag  of  the  current  buffer  is  set  to 
MP_CPUSTART.  Once  it  is  told  to  start,  it  will  get  the  center  row  and 
column  in  blocks  from  the  blkrow  and  blkcol  fields.  Then  it  reads  data 
and  computes  normals.  When  all  processing  is  done,  it  sets  mpflag  to 
MP_CPUDONE,  signaling  the  parent  process  that  the  tile  is  loaded  and 
ready  for  use.  It  then  "swaps"  buffers  to  wait  for  another 
MP.CPUSTART. 

Clipping.  The  majority  of  the  rendering  algorithms  use  the  view  volume 
computed  by  clip  (pg.  A-6).  The  view  volume  is  described  by  the  4  global 
variables  xb,  xe,  yb,  and  ye.  These  represent  beginning  and  ending  indices 
into  the  array  of  elevation  data  which  is  referenced  by  tile->elev. 

Clip  (pg.  A-6)  performs  view  volume  clipping.  For  each  comer  of  the 
screen,  calculates  the  equation  of  a  line  from  the  viewpoint  to  the  comer  in 
3  space  (this  line  is  the  intersection  of  two  clipping  planes),  finds  the  point 
on  the  line  that  is  the  far  clipping  distance  away  from  the  viewpoint,  and 
sets  (or  resets)  the  x  and  y  extents  of  the  view  volume  based  on  the  x  and  y 
coordinates  of  that  point  X  and  y  of  the  viewpoint  are  also  included  in  the 
X  and  y  extents  to  set  the  near  clipping  plane. 

Sampling.  tile->elev  is  a  single  dimensional  pointer  to  the  elevation  data 
to  make  the  storage  more  dynamic,  but  represents  a  two  dimensional  array. 
To  get  the  address  of  a  particular  post  at  row  i,  column  j,  an  offset  is  add^ 
to  tile->elev  which  is  equal  to  i  *  the  number  of  east-west  posts  in  the 
array  +  j.  The  number  of  east- west  posts  in  the  array  is  provided  by  the 
ncols  field  of  the  tile_t  structure.  So  the  address  of  post  (i  j)  =  tile->elev  + 
i  *  tile->ncols  +  j; 

The  other  global  variable  accessed  by  the  majority  of  the  rendering 
algorithms  is  skip.  This  is  the  distance  between  posts  which  will  be 
drawn.  The  elevation  data  being  used  has  a  100  meter  resolution,  so  to 
calculate  the  resolution  at  any  skip  value,  simply  multiply  skip  by  100 
meters.  For  example,  a  skip  of  4  will  display  posts  with  a  400  meter 
resolution.  Values  that  skip  is  allowed  to  take  on  are  1, 2, 4,  and  8. 

Hidden  surface  removal.  Several  of  the  formats  need  to  have  hidden 
pointsAines  removed.  This  is  accomplished  by  drawing  the  terrain  as  a 
black  surface  just  below  the  actual  elevation  data  to  allow  the  zbuffer  to 
correctly  determine  if  the  point  or  line  should  be  drawn  or  not. 
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Silicon  Graphics’  ^phics  library  calls  referenced. 

•  cpack  -  specifies  RGBA  color  with  a  single  packed  32-bit  integer 

•  c3f  -  sets  the  RGB  values  for  the  current  color  vector 

•  n3f  -  specifies  the  surface  normal  of  the  vertex 

•  v3f  -  transfers  a  3-D  vertex  to  the  graphics  pipe 

•  bgnline,  endline  -  delimit  the  vertices  of  a  line 

•  bgnpoint,  endpoint  -  delimit  the  interpretation  of  vertex  routines  as 
points 

•  bgntmesh,  endtmesh  -  delimit  the  vertices  of  a  triangle  mesh 

•  bgnqstrip,  endqstrip  -  delimit  the  vertices  of  a  quad  strip 

Post  tops.  To  draw  the  post  tops,  first  draw  the  hidden  surface,  set  the 
color  of  the  terrain,  and  put  the  graphics  into  a  point  drawing  state  using 
the  bgnpoint  (SG  graphics  library)  call.  Loop  toough  all  of  the  posts 
within  Ae  view  volume  that  are  “skip”  distance  apart,  and  send  the  vertex 
of  that  post  down  the  graphics  pipeline  using  the  v3f  (SG  graphics  library) 
call.  \^^en  all  points  to  by  drawn  have  been  processed,  the  endpoint 
command  signd  is  sent  (SG  graphics  library).  A  variation  of  this 
algorithm  is  used  by  the  emergent  detail  formats.  Instead  of  turning  on  the 
point  at  the  post  tops,  the  points  in  the  middle  of  the  square  determined  by 
the  four  surrounding  post  tops  is  turned  on.  Set  a  temporary  floating  point 
array  to  the  x,  y,  z  values  of  the  point  to  be  drawn,  and  send  that  down  the 
graphics  pipeline  with  the  v3f  (SG  graphics  library)  call. 

Square  post  tops  (Tiles V  Draw  the  hidden  surface,  set  up  the  scalar  values 
to  do  a  bi-linear  interpolation  of  the  elevation  data,  and  sets  the  color  of 
the  terrain.  For  each  post  that  is  within  the  view  volume  at  “skip”  distance 
from  its  neighbors,  define  a  polygon  which  has  four  points  (equidistant 
from  the  post  and  Signed  to  the  grid)  with  a  side  length  of  “reclen”. 

Reclen  is  a  global  variable  that  is  allowed  to  be  alter^  by  using  the  up  and 
down  arrow  keys  on  the  keyboard.  Do  a  bilinear  interpolation  to  get  tire  z- 
values  for  the  current  x,  y  position.  When  all  four  points  are  defined,  put 
the  graphics  in  polygon  mode  with  the  beginpolygon  (SG  graphics  library) 
call,  pass  the  four  vertices  down  the  graphics  pipe,  and  issue  tiie 
endpolygon  (SG  graphics  library)  call  to  take  the  graphics  out  of  polygon 
mode.  TTiis  format  is  also  used  in  the  emergent  detail  formats,  and  the 
hybrid  format,  where  a  square  is  drawn  between  the  posts  instead  of  at  the 
post  tops.  To  do  this,  simply  add  an  offset  to  the  x  and  y  values  before 
finding  the  z-values. 

Wireframe  mesh.  Draw  the  hidden  surface,  and  set  the  terrain  color.  For 
each  line  to  be  drawn  in  the  east-west  direction,  set  the  graphics  into  line 
drawing  mode  with  the  bgnline  (SG  graphics  library)  cdl.  Start  at  the  first 
post  within  the  view  volume  along  this  line,  and  send  each  post  “skip” 
distance  apart  down  the  graphics  pipe  using  the  v3f  (SG  graphics  library) 
call.  When  all  east-west  lines  have  been  drawn,  repeat  the  process  for  Ae 
north-south  lines. 

Hybrid  mesh  and  tiles.  See  the  algorithms  for  the  wireframe  mesh  and  tile 
formats  above. 

Emergent  detail  #1.  See  the  algorithms  for  the  wirefirame  mesh,  post  tops, 
and  tile  formats  above. 

Emergent  detail  #2.  See  the  algorithms  for  the  wireframe  mesh,  post  tops, 
and  tile  formats  above. 
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Optical  expansion  gradient.  This  format  accesses  different  globd 
variables  to  be  able  to  draw  the  scene,  dist  is  accessed  to  determine  haw 
long  the  lines  are  to  be  drawn,  heading  is  accessed  to  determine  the  correct 
orientation  of  the  lines,  and  position  is  accessed  to  compute  the  starting 
point  for  each  line.  Draw  the  hidden  surface,  and  set  the  terrain  color. 
Compute  an  imaginary  horizontal  line  pe^endicular  to  the  current 
heading  that  runs  through  the  position  point.  This  line  provides  the 
starting  x  and  y  coordinates  for  each  line  to  be  drawn.  For  each  point  on 
this  line  which  is  skip  distance  from  its  neighbor  and  within  the  view 
volume,  set  the  graphics  into  line  drawing  mode  with  the  bgnline  (SG 
graphics  library)  call,  and  step  along  the  line  parallel  to  the  heading  to  get 
the  X,  y  values  of  the  next  point  Call  getelev  (pg.  A-31)  to  do  a  bilinear 
interpolation  of  the  data  for  the  z- value.  Pass  the  vertex  of  the  point  to  the 
graphics  pipeline  with  the  v3f  (SG  graphics  library)  call.  When  the  Ime 
extends  beyond  the  view  volume,  start  on  the  next  point  on  the  imaginary 
line. 

Shaded  polygons.  Get  the  first  two  rows  of  elevation  data  within  the  view 
volume.  Set  the  graphics  in  quad  strip  mode  by  using  issuing  the 
bgnqstrip  (SG  graphics  library)  command.  Step  down  the  rows  and  draw 
each  polygon  defined  by  the  two  rows.  Set  the  color  at  each  post  based  on 
its  elevation  (using  elevcolor  (pg.  A-28)),  and  send  the  vertex  down  the 
pipe  using  the  v3f  (SG  graphics  library)  call.  Exit  quad  strip  mode  with 
the  endqstrip  (SG  graphics  library)  command.  When  the  first  two  rows  are 
finished,  use  the  second  and  third  rows,  then  the  third  and  fourth,  and  so 
on  until  all  rows  in  the  view  volume  have  been  drawn. 

Lighted  polygons.  To  draw  light  shaded  polygons,  a  light  model  has  been 
set  up  in  light.c.  The  algorithm  is  then  the  same  as  drawing  shaded 
polygons  with  the  addition  of  specifying  the  surface  norm^ s  at  each  point 
passed  down  the  pipe  with  the  n3f  (SG  graphics  library)  call.  All  surface 
normals  have  been  calculated  by  loadtile  (pg.  A-43)  when  the  data  was 
read  from  the  disk. 

Orthogonal  format.  The  ridgeline  extraction  system  is  incorporated  into 
Setup_dma_grid,  which  is  c^led  by  spawned  process  gridupdate. 
Setup_dma_grid  handles  both  the  ridgeline  extraction  and  tiie  turning 
orAo  extraction,  the  latter  by  calling  Get_high_intersections.  Both  these 
routines  return  lines  as  sets  of  xyz  points  to  be  drawn,  using  a 
“doublebuffer”  system  described  more  fully  below. 

Ridgelines  and  Post  tons.  See  the  algorithm  for  the  post  top  and 
orthogonal  format 

Ridgelines  and  gradient.  See  algorithm  for  the  optical  expansion  gradient 
and  orthogonal  format 

Gridupdate.  Gridupdate  is  a  SPAWNED  PROCESS  that  handles  the 
updates  to  the  GD  STI  format  data  extraction  systems.  It  calls 
Setup_dma_grid  (pg.  A-62)  to  compute  the  points  for  the  orthogonal  turn 
and  ridgeline  formats. 

Setup  dma  grid.  Depending  on  whether  the  STI  format  is  ortho  or  a 
ridgeline  extraction  system,  calls  Get_high_intersections  or 
Ridgeline_extract  for  angles  off  the  current  line  of  sight,  extracting  the 
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information  needed  to  draw  the  lines  representing  the  format  and  storing 
them  in  the  h,  vr,  and  vl  arrays.  When  the  array  is  through  updating,  flips 
toggle  to  allow  access  to  the  new  data. 


4.1.1 .2- E.  Error  detection  and  recovery 

In  the  main  (pg.  A-44)  function,  if  there  are  any  errors  opening  the 
ethemet  connection,  opening  the  terrain  file,  or  if  the  processes  could  not 
be  spawned,  the  program  will  exit  gracefully  and  return  to  the  shell.  In  the 
loadtile  (pg.  A-43)  function,  the  process  will  exit  if  a  block  of  memory 
could  not  be  allocated  or  read.  'Die  getelev  (pg.  A-31)  function  checks  for 
several  errors.  If  the  Tile_t  structures  *tile  does  not  point  to  relevant  data, 
the  function  returns  0.0,  and  if  the  x,y  coordinates  are  not  contained  in  the 
current  tile  in  memory,  out  of  bounds  array  indices  will  be  detected,  and 
0.0  is  returned. 

4.1.1 .2- F.  Data  conversion 

The  GD  format  DMA  data  is  a  32  Mbyte  file  containing  elevations 
covering  about  a  3.5  x  3.5  degree  area  of  the  world.  A  utility, 
Convert_DMA_to_GD_format.c  is  provided  to  convert  16  standard  DMA 
elevation  files  into  this  format.  The  files  to  be  converted  are  listed  in 
“file_list”  a  separate  file.  The  order  is  very  important,  and  is  described 
fully  in  the  routine.  If  you  are  missing  a  file  needed  for  an  area  (not  all 
areas  exist),  the  word  “zeroit”  may  be  used  to  define  a  1x1  degree  area  of 
elevation  zero,  (see  the  Convert_DMA_to_GD_format.c  file  for  further 
information). 

4.1.1 .2- G.  Use  of  other  elements 

Along  with  the  routines  detailed  int  section  4.1.1.2-D,  there  are  a  variety 
of  utilities  used  throughout  the  software  which  provide  basic  functionality. 
Note  that  some  of  the  math  routines  are  duplicated.  This  is  due  to  the  fact 
that  the  routines  have  been  written  to  take  either  floating  point  or  double 
precision  parameters. 

Math  routines: 

perform  vector  normalization 

normalize_vector  (double) 
normalize  (float)  . 
dot  product 

inner_prod 
cross  product 

outer_prod  (double) 
cross  (float) 

Matrix  operations 
set_rotation 
rotate_vector 
initmat 
mpymat 

three  dimensional  distance 
hypot3 

convert  from  compass  angles  to  cartesian  coordinates 
cnv_angle 
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computes  a  vector  between  two  points 
pp2v 

Graphics  routines: 
make_chars 
grafstr 
centstr 


4.1.1 .2- H.  Logic  flow 
See  processing  flow  diagram. 

4.1.1 .2- 1.  Data  structures 


The  following  are  data  structures  defined  for  the  STI  program. 

4. 1 . 1 .2-1. 1  Post  type  is  the  definition  of  an  elevation  data  post  It 

specifies  the  position  of  the  data  post,  and  its  surface  normal.  The  loadtile 
process  reads  the  elevation  data  from  the  disk,  and  sets  the  different  fields 
of  the  data  structure  based  on  what  was  read  from  the  disk.  The  rendering 
routines  then  access  the  vertices  and  normals  of  the  data  posts  as  required. 


typedef  struct 
{ 

float  nx; 
float  ny; 
float  nz; 
float  nw; 
float  vx; 
float  vy; 
float  vz; 
float  vw; 

}  Post_t; 


/*  X  component  of  the  surface  normal  (feet)*/ 
/*  y  component  of  the  surface  normal  (feet)*/ 
/*  z  component  of  the  surface  normal  (feet)*/ 
/*  unused  */ 

/*  X  component  of  the  vertex  (feet)*/ 

/*  y  component  of  the  vertex  (feet)*/ 

/*  z  component  of  the  vertex  (feet)*/ 

/*  height  of  the  black  surface  for  hidden 
ptAine  removal  */ 


4.1.1 .2-1.2  The  Tile  type  structure  fully  describes  the  block  of 
elevation  data  resident  in  RAM.  The  STI  program  uses  two  of  these 
structures.  First,  there  is  an  array  of  size  two  of  these  structures.  This  is  to 
facilitate  the  “double  buffered”  approach  for  multiprocessing.  The  loadtile 
process  will  read  data  from  the  disk  and  set  up  the  structure  in  one  buffer 
while  the  rest  of  the  program  uses  the  data  in  the  other  buffer.  When 
loadtile  is  finished  loading  the  current  tile,  the  buffers  are  swapped,  and 
then  loadtile  starts  loading  a  new  tile  while  the  rest  of  the  program  uses  Ae 
previously  loaded  tile.  The  second  stracture  of  this  type  is  a  pointer.  It  is 
always  set  to  point  to  the  most  recently  loaded  buffer  of  the  array 
mentioned  above.  This  is  done  so  all  of  the  routines  don’t  have  to  have  to 
keep  track  of  which  buffer  they  are  supposed  to  be  using.  (See 
descriptions  of  managememory  and  loadtile  for  further  information  about 
the  “double  buffered”  multiprocessing  approach.) 
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typedef  struct 

{ 

int  mpflag;  /*  flag  for  communication  between 

processes  */ 

int  nrows;  /*  number  of  rows  of  data  posts  in 

this  tile  */ 

int  ncols;  /*  number  of  columns  of  data  posts 

in  this  tile  */ 

int  blkrow;  /*  row  number  of  the  center  block 

from  the  data  file  */ 

int  blkcol;  /*  column  number  of  the  center 

block  from  data  file  */ 

float  wedge;  /*  western  edge  (in  feet)  of  the  tile  */ 

float  sedge;  /*  southern  edge  (in  feet)  of  the  tile  */ 

float  minelev;  /*  minimum  elevation  (in  feet)  of  this  tile  */ 

float  maxelev;  /*  maximum  elevation  (in  feet)  of 

this  tile  */ 

Post_t  *elev;  /*  pointer  to  the  array  of  elevation  posts  */ 

}  Tile_t; 

4. 1.1. 2-1.3  The  following  structure  is  one  of  the  two  stmctures  which 
are  passed  over  the  ethemet.  This  allows  the  simulation  to  get  ownship 
flight  parameters.  Note  that  this  structure  contains  a  subset  of  the 
target_type  described  below.  Also  note  that  the  HMD  rotation  data  is 
provided  over  the  ethemet  by  the  simulation  driving  the  SH  program. 

The  air_pos  data  is  specified  in  feet,  and  is  relative  to  an  arbitrary  origin. 
The  wedge  and  sedge  fields  of  the  terrain_type  packet  (see  below)  are 
offsets  specified  in  the  same  coordinate  systenx 


struct  etherown_type 

{ 


y  sfc  ;ie  3(e }ie  4;  :fc  ;>ic  9|c  3|e  :1c  :1c  3|c  ^  :tc  )fc  ak  sfc  ifc  ak  afc  3fc  3k  %  ifc  %  3k  sic  9fc  %  :|e  4c  3k  4c  afc  3k  4c  sfe  sfe  4c  sic  4c  9|e  3|e 


*  Right  model  stracture  * 


int  id; 

int  flags; 

int  index;  /*  target  index  */ 

int  type;  /*  target  type  */ 


double 

air  pos[3]; 

/*  X,  y,  z  position  (feet)  */ 

double 

u0[3]; 

/*  unit  vector  defining  right  wing  */ 

double 

ul[3]; 

/*  unit  vector  defining  nose  */ 

double 

u2[3]; 

/*  unit  vector  normal  to  airframe.  */ 

double 

velocity[3]; 

double 

filt_throttle; 

double 

fuel; 

double 

fuel_flow; 

double 

g_norm; 

double 

mach; 

double  lookx,  looky,  lookz;  /*  HMD  rotations  (degrees)  */ 
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4.1.1 .2-1.4  The  target_type  structure  more  fully  describes  the  flight 
parameters  of  ownship.  The  values  which  correspond  to  the  same  fields  of 
the  etherown_type  are  extracted  from  the  etherown_type  packet  which  is 
sent  over  the  eAemet.  The  remaining  fields  can  be  calculated  from  the 
data  which  was  provided  over  the  ethemet. 


struct  target_type 

y*********************************************************** 

*  Flight  model  structure  * 

***********************************************************/ 


int  id; 

int  flags; 

int  index;  /*  target  index  */ 

int  type;  /*  target  type  */ 

double  air_pos[3]; 

double  u0[3]; 

double  ul[3]; 

double  u2[3]; 

double  velocity[3]; 

double  filt_throttle; 

double  fuel; 

double  fuel_flow; 

double  g_norm; 

double  mach; 

double  lookx,  looky,  lookz;  /*  HMD  rotations.  */ 

/*  The  following  variables  are  USEFUL  but  can  be  DERIVED  from  the 
above  data;  they  are  NOT  sent  over  ethemet..  */ 

double  compass; 

double  ground_course; 

double  ground_speed; 

double  airspeed; 

double  roll_angle; 

double  dive_angle; 

double  frame_dive; 

double  side_slip; 

double  aoa; 

double  radar_alt; 

double  stpt_x,  stpt_y;  /*  steerpoint  symbol 

location  in  HUD 
coordinates.  */ 

int  alt,  vel;  /*  flags  for  altimeter  option,  (RADAR,  B ARO, 

AUTO)  and  as/  option  (CAL,  TAC,  GROUND).  */ 
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4. 1.1. 2-1.5  And  finally,  the  terrain_type  packet  is  used  to  describe  the 

preprocessed  DTED  file.  The  only  parts  of  the  terrain_type  packet  that  are 
currently  used  are  the  wedge  and  sedge  values. 

/*  This  is  the  terrain  parameter  structure  used  for  terrparm.  */ 
struct  terrain_type 
{ 

int  id; 
int  flags; 

/*  the  terrain  flags...  */ 
int  wedge,  sedge,  terrain; 

char  terrain_path[80];  /*  pathname  to  the  current  terrain  file, 
w/out  extension  */ 
int 
int 
int 
int 
int 
int 
int 

}; 


synterr;  /*  synthetic  terrain  format.  */ 

hidden;  /*  hidden  surface  removal,  on/off  */ 
depth;  /*  depthcuing  on/off  */ 

skip;  /*  sampling  resolution  of  terrain.  */ 

reclen;  /*  side  length  of  the  square  posts  (feet).  */ 

fat;  /*  toggle  double  width  on/off.  */ 

faredge;  /*  distance  top  far  clipping  plane.  */ 
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APPENDIX  A 

Software  Routines 


To  run: 

%  Sn  -ens  terrain.dma 
Options: 

-e  enables  CD’s  ethemet  protocol.  Don’t  need  to  supply  a  file  name  with  this  option  because 
a  filename  is  asked  for  over  the  ethemet. 

-n  sets  the  video  output  of  the  computer  to  RS-170A  video  format 
-s  displays  the  terrain  in  a  RS-170A  sized  window 

Note: 

The  terrain  file  is  needed  in  all  cases  except  when  using  the  ethemet. 

operator  key  commands: 

ESCKEY: 

FIKEY: 

F2KEY: 

F3KEY: 

F4KEY: 

F5KEY: 

F6KEY: 

F7KEY: 

F8KEY: 

F9KEY: 

FIOKEY: 

FllKEY: 

F12KEY: 

I/OKEY: 

UP/DOWNARROW: 

CKEY: 

PKEY: 

QKEY: 

HKEY: 

M/LKEY: 

B/DKEY: 

TKEY: 

VKEY: 
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exit 

set  format  to  point  post  tops 
set  format  to  polygonal  post  tops 
set  format  to  wireframe  mesh 
set  format  to  wireframe  mesh  with  polygonal 
posts  in  the  center  of  the  mesh 
set  format  to  emergent  detail,  grid  >  2000,  grid  plus  points 
>  750  &  <  2000,  grid  plus  square  posts  <  750 
set  format  to  emergent  detail,  points  >  2000,  grid  >  750  & 

<  2000,  grid  plus  square  posts  <  750 
set  format  to  Optical  Expansion  Gradient 
set  format  to  Lighted  Polygons 
set  format  to  Elevation  shaded  Polygons 
set  format  to  CD's  orthogonal  format 
set  format  to  ridgelines  +  post  tops 
set  format  to  ridgelines  +  gradient 
increase/decrease  the  spacing  between  posts. 

spacing  can  take  on  die  values  of  100, 200, 400  or  800  meters, 
increase/decrease  the  side  length  of  the  polygonal  posts 
toggle  depth  cueing 
toggle  horizon  line  on/off 
toggle  single  or  double  width  lines 
toggle  hidden  point/line  removal 
increase/decrease  the  distance  to  local  horizon 
brighten/darken  the  STI 
toggle  display  of  terrain  on/off 
toggle  variable  local  horizon  on/off 


S/AKEY :  increase/decrease  velocity 

HOMEKEY :  return  simulation  to  original  position 

L/RTMOUSE:  slew  the  helmet 

MIDDLEMOUSE:  reset  helmet  to  0 

MOUSE  POSITION: 

MOUSEX:  roll  of  the  plane 

MOUSEY :  pitch  of  the  plane 

to  turn,  roll  the  plane  about  90  degrees,  and  then  pull 
back  on  the  mouse. 
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ROUTINE: 

Angle_computations 

FILE: 

ethemet.c 

DESCRIPTION: 

The  data  in  the  packet  sent  over  the  ethemet  contains 
the  unit  vectors  detennineing  the  A/C  orientation,  the 
velocity  vector,  and  other  mathematical  data.  This  routine 
derives  the  compass  heading,  pitch  and  roll,  airspeed, 
groundspeed,  AOA,  dive  angle,  ground  course  and  other 
“aircraft”  data  from  the  raw  vector  data.  BOTH  types  are 
used  by  the  system,  and  to  preserve  ethemet  bandwidth 
the  larger  set  of  data  is  derived  from  the  smaller. 
PARAMETERS: 

os  wind  calc_all_values 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  HISTORY: 

0.0  GD  original. 


ROUTINE: 

centstr 

FILE: 

grf.c 

DESCRIPTION: 

Draws  a  character  string  at  current  location.  Leaves  the 
current  location  at  the  end  of  the  string.  Draws  the  string 
from  the  center  of  the  first  letter. 

PARAMETERS: 

None 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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/* 

**  ROUTINE: 

**  chgtercolor 

**  DESCRIPTION: 

**  Changes  the  terrain  color  from  its  current  value. 

**  PARAMETERS: 

**  val  i  relative  value  to  change  the  terrain  color 

** 

**  GLOBALS  ACCESSED: 

**  tercol  o  packed  RGB  color 

**  intensity  i/o  current  green  intensity  of  terrain 

** 

**  USER  ROUTINES  CALLED: 

**  None 

**  REVISION  fflSTORY 

**  0.0  dcrobohm  92/11  original 

*1 
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I* 

**  ROUTINE: 

**  clip 

**  DESCRIPTION: 

**  Performs  view  volume  clipping.  For  each  comer  of  the  screen, 
**  calculates  the  equation  of  a  line  from  the  viewpoint  to  the 
**  comer  in  3  space  (this  line  is  the  intersection  of  two  clipping 

**  planes),  finds  the  point  on  the  line  that  is  the  local  horizon 

**  distance  away  from  the  viewpoint,  and  sets  (or  resets)  the  x  and 
**  y  extents  of  Ae  view  volume  based  on  the  x  and  y  coordinates  of 
**  that  point,  x  and  y  of  the  viewpoint  are  also  included  in  the  x 
**  and  y  extents  to  set  the  near  clipping  plane. 


3le4e 

PARAMETERS: 

pos[3]  i 

viewpoint  position 

ak* 

v0[3]  i 

normalized  vector  pointing  to  the  right 

akak 

vl[3]  i 

normalized  line  of  sight  vector 

ak* 

v2[3]  i 

normalized  vector  pointing  up 

akak 

fov  i 

field  of  view  in  screen  y  d^ection 

3k  ak 

aspect  i 

aspect  ratio  of  screen  x  to  screen  y 

akak 

akak 

dist  i 

distance  to  the  local  horizon 

**  GLOBALS  ACCESSED: 


akak 

xb 

0 

beginning  x  extent  of  view  volume 

akak 

xe 

0 

ending  x  extent  of  view  volume 

akak 

yb 

0 

beginning  y  extent  of  view  volume 

akak 

akak 

ye 

o 

ending  y  extent  of  view  volume 

**  USER  ROUTINES  CALLED: 
**  None 

♦♦  REVISION  fflSTORY 
**  0.0  dc  robohm  i 

**  1.0  dc  robohm  * 


92/09  original 

92/10  moiled  so  it  uses  the  three  unit 
vectors,  removed  procedure  calls,  and 
directly  sets  the  x  and  y  extents. 
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/* 

**  ROUTINE: 

**  closedmafile 

**  DESCRIPTION: 

**  Closes  the  file  pointed  to  by  dmafp,  if  dmafp  points  to  a  file. 

**  PARAMETERS: 

**  None 

**  GLOBALS  ACCESSED: 

**  dmafp  i  file  pointer  to  open  dted  file 

** 

**  USER  ROUTINES  CALLED: 

**  None 

**  REVISION  fflSTORY 

**  0.0  dcrobohm  92/09  original 

*1 
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/* 

**  ROUTINE: 

**  colour 

**  DESCRIPTION: 

**  Sets  the  current  color  based  on  index  given. 

**  PARAMETERS: 

**  index  i  determines  which  color  to  set 

**  GLOBALS  ACCESSED: 

**  tercol  o  packed  RGB  color  of  the  terrain 

**  USER  ROUTINES  CALLED: 

**  None 
** 

**  REVISION  HISTORY 

**  0.0  dcrobohm  92/09  original 

**  0.1  dcrobohm  92/11  added  index  for  terrain  color 

*/ 
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/♦ 

**  ROUTINE: 

**  control 
** 

**  DESCRIPTION: 

**  Polls  the  keyboard  for  operator  input,  updates  the  position  of  the 
**  plane,  updates  the  tile  block  in  memory,  sets  up  the  viewing 
**  transformation,  clips  the  terrain  to  the  view  volume,  and  draws 
**  the  graphics  for  the  current  position.  This  process  is  continued 
**  in  a  loop  until  the  operator  presses  the  escape  key  to  exit.  Once 
**  the  ethemet  code  from  GD  is  integrated,  the  mouse  will  no  longer 
**  be  used  to  update  the  position  of  Ae  plane. 


operator  key  commands: 
ESCKEY: 

FIKEY: 

F2KEY: 

F3KEY: 

F4KEY: 

F5KEY: 


F6KEY: 

F7KEY: 

F8KEY: 

F9KEY: 

FIOKEY 

FllKEY 

F12KEY 

VOKEY: 


UP/DOWNARROW: 

CKEY: 

PKEY: 

QKEY: 

HKEY: 

M/LKEY: 

B/DKEY: 

TKEY: 

VKEY: 

S/AKEY: 

HOMEKEY: 

L/RTMOUSE: 

MIDDLEMOUSE: 


exit 

set  format  to  point  post  tops 
set  format  to  polygonal  post  tops 
set  format  to  wireframe  mesh 
set  format  to  wireframe  mesh  with  polygonal 
posts  in  the  center  of  the  mesh 
set  format  to  emergent  detail,  grid  >  2000, 
grid  plus  points  >  750  &&  <  2000,  grid  plus 
square  posts  <750 

set  format  to  emergent  detail,  points  >  2000, 
grid  >  750  &&  <  2000,  grid  plus  square  posts  <  750 
set  format  to  Optical  Expansion  Gradient 
set  format  to  Lighted  Polygons 
set  format  to  Elevation  sh^ed  Polygons 
set  format  to  GD's  orthogonal  format 
set  format  to  ridgelines  +  post  tops 
set  format  to  ridgelines  +  gradient 
increase/decrease  the  spacing  between  posts, 
spacing  can  take  on  the  values  of  100, 200, 400 
or  800  meters. 

increase/decrease  the  side  length  of  the 
polygonal  posts 
toggle  depth  cueing 
toggle  horizon  line  on/off 
toggle  single  or  double  width  lines 
toggle  hidden  point/line  removal 
increase/decrease  the  distance  to  local  horizon 
brighten/darken  the  STI 
toggle  display  of  terrain  on/off 
toggle  variable  local  horizon  on/off 

increase/decrease  velocity 
return  simulation  to  original  position 
slew  the  helmet 
reset  helmet  to  0 


**  PARAMETERS: 
**  enet  i 

**  mode  i 


flag  to  determine  ethemet  use,  or  standalone 
0  for  standalone,  !0  for  ethemet 
graphics  mode,  NTSC  size  or  full  screen 
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** 


**  GLOBALS  ACCESSED: 


** 

depth 

o 

depth  cueing  on  or  off 

aleak 

dist 

o 

distance  to  local  horizon 

♦ak 

fat 

o 

fat  lines  on  or  off 

akak 

heading 

o 

heading  of  the  plane 

akak 

hidden 

0 

hidden  points/lines  on  or  off 

akak 

position 

o 

position  of  the  plane 

akak 

reclen 

0 

sidelength  of  polygonal  posts 

akak 

akak 

skip 

i/o 

spacing  between  posts 

**  GD  ROUTINES  CALLED: 
**  Angle_computations 
**  Draw_new_hmd 
*♦  Radar_alt 
♦♦  rcv_ethemet 
**  Send_ctrl_msg_to_hud 


**  REVISION  fflSTORY 


akak 

0.0 

dc  robohm 

92/09 

original 

akak 

0.1 

dcrobohm 

92/09 

added  code  to  interface  ethemet. 

akak 

1.0 

dc  robohm 

92/09 

renamed  from  animate  to  control 

akak 

1.1 

dc  robohm 

92/11 

added  for  fog  for  depth  cueing 

♦/ 
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**  REVISION  fflSTORY 

**  0.0  dcrobohm  92/09  original 

*/ 
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/* 

**  ROUTINE: 

**  cross 
** 

**  DESCRIPTION: 

**  Computes  the  cross  product  of  two  vectors. 
** 

**  PARAMETERS: 


vl 

i 

vector  1 

v2 

i 

vector  2 

** 

c 

0 

contains  vl  x  v2 

**  GLOBALS  ACCESSED: 

**  None 

:|c* 

**  USER  ROUTINES  CALLED: 

**  None 

**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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/* 

**  ROUTINE: 

**  depthcoef 

** 

**  DESCRIPTION: 

**  Sets  the  coeficients  for  doing  linear  depth  cueing,  color  values 
**  can  range  from  O..Oxff. 


afeafe 

PARAMETERS: 

dist 

i 

distance  over  which  the  colors  are  linearly  mapped 

mine 

i 

minimum  color,  this  color  will  be  displayed  at 

** 

distance  dist  from  viewer 

** 

maxc 

i 

maximum  color,  this  color  will  be  displayed  at 

** 

a)ea|c 

the  viewer  position 

GLOBALS  ACCESSED: 

** 

cl 

o 

coeficient.  out  =  in  *  cl  +  c2; 

** 

** 

c2 

0 

coeficient.  out  =  in  *  cl  +  c2; 

**  USER  ROUTINES  CALLED: 

**  None 
** 

**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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/* 

** 

** 

** 

** 

♦  * 
** 
** 
** 
** 
** 
** 
** 
** 
** 
*3te 

*/ 


ROUTINE: 

depthcolor 

DESCRIPTION: 

Returns  the  color  according  to  depth.  If  depth  is  true,  depth 
cueing  is  on,  so  find  the  distance  in  the  x,y  plane  (note  we  are 
not  using  3D  distances)  and  return  the  color  according  to 
coir  =  dist  *  cl  +  c2.  Otherwise,  retimi  the  maximum  color, 
which  is  defined  to  be  c2.  The  retirni  value  is  of  the  format  suited 
for  the  cpack  call  (i.e.  OxAABBGGRR). 

PARAMETERS: 

pnt[3]  i  point  for  which  color  needs  to  be  determined 

depth  i  flag  to  tell  if  depth  cueing  is  on  or  off 

GLOBALS  ACCESSED: 

cl  i  coeficient.  out  =  dist  *  cl  +  c2; 

c2  i  coeficient.  out  =  dist  *  cl  +  c2; 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY 

0.0  dc  robohm  92/09  original 
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/* 

**  ROUTINE: 

**  dot 

**  DESCRIPTION: 

**  Returns  the  dot  product  of  two  vectors. 

** 

**  PARAMETERS: 

**  vl  i  vector  1 

**  v2  i  vector  2 

**  GLOBALS  ACCESSED: 

**  None 

**  USER  ROUTINES  CALLED: 

**  None 
** 

**  REVISION  fflSTORY 

**  0.0  dciobohm  92/09  original 

*/ 
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ROUTINE: 

Draw_dma_grid 

FILE: 

GDrender.c 

DESCRIPTION: 

Takes  the  arrays  as  set  up  by  Setup_dma_grid  and 
Get_high_intersections  and  draws  them. 
PARAMETERS; 

None 

GLOBALS  ACCESSED: 
toggle 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

Draw_dma_ridge 

FILE: 

GDrender.c 

DESCRIPTION: 

Takes  the  arrays  as  set  up  by  Setup_dma_grid  and 
Ridgeline_extract  and  draws  them. 
PARAMETERS: 

None 

GLOBALS  ACCESSED: 
toggle 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

drawgradient 

DESCRIPTION: 

Draws  the  terrain  as  an  optical  expansion  gradient.  Queries  the 
elevation  data  to  get  the  elevation  of  points  along  lines  running 
parallel  to  the  motion  of  the  plane  and  draws  those  lines. 

PARAMETERS: 

None 


GLOBALS  ACCESSED: 

dist  i  to  determine  how  long  the  lines  are 

heading  i  to  get  the  orientation  of  the  lines 

position  i  to  get  the  starting  point  of  each  line 

skip  i  to  get  the  spacing  between  the  lines 

USER  ROUTINES  CALLED: 
cnv_angle 
colour 
getelev 


**  REVISION  fflSTORY 
**  0.0  dc  robohm 

**  0.1  dc  robohm 

** 


** 


*1 


92/09  original 

92/1 1  removed  call  to  depthcolor,  and  added 
call  to  colour  since  fog  is  now  being 
used  for  depth  cueing  instead  of 
computing  the  color  at  each  vertex 


ROUTINE: 

Draw_hmd_alt_tape 

FILE: 

hind.c 

DESCRIPTION: 

Draws  the  digital  altitude  readout. 
PARAMETERS: 

altitude  radar 
GLOBALS  ACCESSED: 
none 

USER  ROUTINES  CALLED: 
grafstr 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 

Radar  is  a  flag  for  whether  altitude  is  baro  or  radar. 
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ROUTINE: 

Draw_hmdinagheading_tape 

FILE: 

hmd.c 

DESCRIPTION: 

Draws  the  heading  scale. 
PARAMETERS: 

planeheading  head_adj 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 
grafstr 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 


ROUTINE: 

Draw_hmd_thenno 

FILE: 

hmd.c 

DESCRIPTION: 

Draws  the  “thermometer”  style  radar  altimeter. 
PARAMETERS: 
alt 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 
grafstr 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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/* 

**  ROUTINE: 

**  drawmesh 

**  DESCRIPTION: 

**  Draws  the  terrain  as  a  square  grid  wireframe  mesh. 


**  PARAMETERS: 
**  none 


**  GLOBALS  ACCESSED: 


3k  ak 

skip 

i 

** 

tile 

i 

ak* 

xb 

i 

akak 

xe 

i 

akak 

yb 

i 

akak 

akak 

ye 

i 

determines  the  resolution  of  the  data  samples 
for  the  elevation  data,  and  array  bounds 
beginning  x  extent  of  view  volume 
ending  x  extent  of  view  volume 
beginning  y  extent  of  view  volume 
ending  y  extent  of  view  volume 


He* 


USER  ROUTINES  CALLED: 
colour 


**  REVISION  HISTORY 

**  0.0  dc  lobohm 

**  0.1  dciobohm 

** 

** 

4caic 

*/ 


92/09  original 

92/1 1  removed  call  to  depthcolor,  and  added 
call  to  colour  since  fog  is  now  being 
used  for  depth  cueing  instead  of 
computing  the  color  at  each  vertex 


A-22 


ROUTINE: 

Draw_new_hmd 

FILE: 

hmd.c 

DESCRIPTION: 

Draws  the  hmd  symbology  over  the  STI  formaL 
PARAMETERS: 

os,  lookvec,  hmd_los 
GLOBALS  ACCESSED: 

hmd_fov_xl  hmd_fov_x2  hmd_fov_yl  hmd_fov_y2 
offset 

USER  ROUTINES  CALLED: 

Draw_hmd_airspeed 
Draw_hmd_thermo 
Draw_hmd_alt_tape 
Draw_hmdmagheading_tape 
Draw_steerpoint 
REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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**  ROUTINE: 

**  drawpoints 

4caie 

**  DESCRIPTION: 

**  Draws  the  terrain  as  post  tops.  Simply  turns  on  one  pixel  at  the 
**  desired  position.  If  offset  is  FALSE,  draws  the  p>oint  at  the  post  top, 
**  otherwise,  draws  the  point  in  the  center  of  the  four  surrounding 
**  posts. 


**  PARAMETERS: 
**  offset  i 


flag  to  determine  if  the  point  are  to  be  drawn 
at  die  posts,  or  offset  between  the  posts 


GLOBALS  ACCESSED: 


skip 

tile 

xb 

xe 

yb 

ye 


i  determines  the  resolution  of  the  data  samples 
i  for  the  elevation  data,  and  array  bounds 
i  beginning  x  extent  of  view  volume 

i  ending  x  extent  of  view  volume 
i  beginning  y  extent  of  view  volume 

i  ending  y  extent  of  view  volume 


**  USER  ROUTINES  CALLED: 
**  colour 
**  getelev 


**  REVISION  HISTORY 


*/ 


0.0 

0.1 


dcrobohm 
dc  robohm 


92/09  original 

92/1 1  removed  call  to  depthcolor,  and  added 
call  to  colour  since  fog  is  now  being 
used  for  depth  cueing  instead  of 
computing  the  color  at  each  vertex 
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/* 

**  ROUTINE: 

**  drawpolys 

**  DESCRIPTION: 

**  Draws  the  terrain  as  elevation  shaded  polygons  depending  on  the 
**  value  of  the  light  flag. 

**  PARAMETERS: 

**  light  i  flag  to  determine  light  shading 

**  GLOBALS  ACCESSED: 

**  skip  i  determines  the  resolution  of  the  data  samples 

**  tile  i  for  the  elevation  and  normal  data,  and  array  bounds 

*♦  xb  i  beginning  x  extent  of  view  volume 

**  xe  i  ending  X  extent  of  view  volume 

**  yb  i  beginning  y  extent  of  view  volume 

**  ye  i  ending  y  extent  of  view  volume 

** 

**  USER  ROUTINES  CALLED: 

**  elevcolor 

** 

**  REVISION  fflSTORY 

**  0.0  dcrobohm  92/09  original 

*/ 
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ROUTINE: 

Draw_steeipoint 

FILE: 

hmd.c 

DESCRIPTION: 

Draws  the  steerpoint  symbol. 
PARAMETERS: 
os 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 
grafstr 

flex_limit_symbol 
REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 


/* 


** 

ROUTINE: 

** 

:fc9fe 

drawsquares 

** 

DESCRIPTION: 

sic  4c 

Draws  the  terrain  as  square  post  tops.  If  offset  is  FALSE,  draws  the 

4c  4c 

square  at  the  post  top,  otherwise,  draws  the  square  in  the  center 

4c  4c 

4c  4c 

of  the  four  surrounding  posts. 

4c  4c 

PARAMETERS: 

4c  4c 

offset 

i  flag  to  determine  if  the  squares  are  to  be  drawn 

4c  4c 

4c  4c 

at  *e  posts,  or  offset  between  the  posts 

4c4c 

GLOBALS 

ACCESSED: 

4c  4c 

skip 

i  determines  the  resolution  of  the  data  samples 

4c* 

tile 

i  for  the  elevation  data,  and  array  bounds 

4c  4c 

xb 

i  beginning  x  extent  of  view  volume 

4c  4c 

xe 

i  ending  x  extent  of  view  volume 

4c  4c 

yb 

i  beginning  y  extent  of  view  volume 

4c  4c 

4c  4c 

ye 

i  ending  y  extent  of  view  volume 

4c  4c 

USER  ROUTINES  CALLED: 

4c  4c 

4c  4c 

colour 

4c* 

REVISION  HISTORY 

** 

0.0 

dc  robohm 

92/09  original 

** 

1.0 

dcrobohm 

92/10  rewrote  the  subroutine  to  remove 

** 

subroutine  calls,  now  do  the  bilinear 

4c  4c 

interpolation  within  this  subroutine  so 

** 

we  only  have  to  set  up  the  coefficients 

** 

once  for  every  frame,  instead  of  once 

** 

for  each  of  the  four  comer  points  of 

** 

each  square  in  the  frame. 

** 

1.1 

dc  robohm 

92/1 1  removed  call  to  depthcolor,  and  added 

** 

call  to  colour  since  fog  is  now  being 

** 

used  for  depth  cueing  instead  of 

** 

computing  the  color  at  each  vertex 

*/ 
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/* 

**  ROUTINE: 

**  elevcolor 

**  DESCRIPTION: 

**  Returns  the  color  from  sti_colnnap  based  on  the  given  elevation. 

**  the  format  of  the  color  is  suitable  for  the  cpack  cil  (i.e. 

**  OxAABBGGRR). 

**  PARAMETERS: 

**  z  i  elevation  for  which  the  color  is  needed 

** 

*♦  GLOBALS  ACCESSED: 

**  sti_colrmap  i  contains  the  elevation  colors 


**  USER  ROUTINES  CALLED: 


none 


**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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/4c 

**  ROUTINE; 

**  fastlight 

4c4c 

**  DESCRIPTION: 

**  Fastlight  is  provided  so  the  light  may  be  bound  after  the 
**  tansformation  matrix  has  been  set  up.  This  is  so  the  light 
**  remains  fixed  to  the  ground  as  opposed  to  being  fixed  in 

**  viewer  space. 

** 

**  PARAMETERS: 

**  None 
** 

**  GLOBALS  ACCESSED: 

**  None 

4c  4c 

**  USER  ROUTINES  CALLED: 

**  None 

**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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ROUTINE: 

flex_liimt_symbol 

FILE: 

hmd.c 

DESCRIPTION: 

Limits  the  coordinates  passed  to  it  to  the  passed  down 
field  of  view;  returns  true  if  position  was  limited. 
PARAMETERS: 

pos  (xy),  fovxl,  fovx2,  fovyl,  fovyl 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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/* 

**  ROUTINE: 
**  getelev 


*♦  DESCRIPTION: 

**  Does  a  bi-linear  interpolation  of  the  DTED  to  get  and  return  the 
elevation  at  point  x,y.  If  point  x,y  is  not  contained  in  the 
current  tile,  0.0  is  returned.  Uses  the  global  variable  skip  to 
use  only  the  posts  that  would  be  present  had  the  data  been  at 
skip  *  100  resolution. 


** 

** 


**  PARAMETERS: 
**  X  i 

♦  ♦  y  j 

** 


X  position  (in  feet)  of  desired  elevation 
y  position  (in  feet)  of  desired  elevation 


**  GLOBALS  ACCESSED: 


skip 

i 

determines  which  posts  are  used  for  interpolation 

tile 

i 

access  wedge,  sedge,  mows,  and  ncols  to 

** 

determine  where  this  point  is  in  relation  to 

** 

the  current  elevation  tile,  and  elev  to 

** 

** 

determine  the  elevation. 

**  USER  ROUTINES  CALLED: 
**  None 


**  REVISION  fflSTORY 

**  0.0  dcnobohm  92/09  original 

*/ 
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ROUTINE: 

Get_high_intersections 

FILE: 

GDrender.c 

DESCRIPTION: 

Get_high_intersections  projects  from  point  down  los.  It  stores 
the  point  encountered  at  the  highest  visual  angle  so  far  as  it  projects. 
As  the  projection  proceeds,  the  distance  traversed  along  the  HMD 
los  and  across  it  is  tracked.  As  these  distances  cross  the 
horizontal  and  vertical  criteria  passed  down  by  Setup_dma_grid, 
the  current  point  is  added  to  the  appropriate  array  (h,  vl  or  vr) 
to  extend  that  line. 

PARAMETERS: 

point  —the  starting  point  of  the  projection. 

los  —unit  vector  defining  line  of  sight  to  look  down. 

near  —distance  criteria  for  nearest  horizontal  line. 

11  —distance  criteria  for  2nd  horizontal  line. 

12  —for  3rd  horizontal  line, 
far  -for  4th  horizontal  line 
si  —for  first  vertical  line  out. 

(note:  Get_high_intersections  is  called  SEPARATELY  to 
determine  the  ^d  to  the  left  and  right  of  the  LOS. ) 
s2  —next  vertical  line  out. 
s3,  s4  —next  vertical  line  criteria, 
vdf  —proportion  of  the  projected  line  in  the 
-direction  of  the  LOS. 

hdf  —proportion  of  the  projected  line  normal  to  the  LOS. 
h  —array  holding  the  horizontal  line  points. 

V  —array  holding  the  vertical  line  points, 
nph  —number  of  |X)ints  in  the  horizontal  line  arrays, 
npv  —number  of  i^ints  in  the  vertical  line  arrays, 
flag  —determines  if  left  or  right  of  LOS . 

GLOBALS  ACCESSED: 
toggle 

USER  ROUTINES  CALLED: 

REVISION  HISTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

grafstr 

FILE: 

grf.c 

DESCRIPTION: 

Draws  a  character  string  at  current  location.  Leaves  the 
current  location  at  the  end  of  the  string.  Draws  the  string 
from  the  lower  left  comer  of  the  first  letter. 
PARAMETERS: 
none 

GLOBALS  ACCESSED: 
none 

USER  ROUTINES  CALLED: 
none 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

gridupdate 

FILE: 

GDrender.c 

DESCRIPTION: 

SPAWNED  PROCESS  that  handles  the  updates  to  the  GD  STI 
format  data  extraction  systems. 

PARAMETERS: 

none 

GLOBALS  ACCESSED: 
none 

USER  ROUTINES  CALLED: 

Setup_dma_grid 
REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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/* 

♦♦ 
*♦ 
** 
akafc 
** 
** 
*♦ 
*♦ 
** 
*♦ 
♦* 
♦* 
♦♦ 
♦  4t 
♦♦ 
** 
*♦ 
*♦ 
** 
*♦ 
** 
*♦ 

*/ 


ROUTINE: 

hide 

DESCRIPTION: 

Performs  hidden  point/line  removal  by  drawing  the  terrain  with 
black  polygons.  The  vw  coordinate  of  the  post  type  was  originally 
intended  as  a  buffer  to  more  efficiently  align  the  data  in  memory, 
since  it  is  already  in  memory,  use  it  to  cheat  the  zbuffer  by 
setting  it  to  less  than  vz  coordinate  (the  actual  elevation). 

When  the  black  polygons  are  drawn,  use  the  vw  coordinate  for 
elevation  instead  of  vz. 

PARAMETERS: 

None 


GLOBALS  ACCESSED: 

skip  i  determines  the  resolution  of  the  data  samples 
tile  i  for  the  elevation  data,  and  array  bounds 

xb  i  beginning  x  extent  of  view  volume 

xe  i  ending  x  extent  of  view  volume 

yb  i  beginning  y  extent  of  view  volume 

ye  i  ending  y  extent  of  view  volume 


USER  ROUTINES  CALLED: 
colour 


REVISION  fflSTORY 
0.0  dc  robohm 

0.1  dc  robohm 


92/09  original 

92/10  added  code  to  always  draw  the  black 
squares  with  a  valley,  due  to  the 
nature  of  the  origin^  method,  sometimes 
there  would  be  ^aks  in  the  squares,  and 
sometimes  there  would  be  valleys, 
the  peaks  would  obscure  anything  drawn 
between  the  posts,  so  a  method  was  needed 
to  draw  only  valleys. 
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ROUTINE: 

hypotS 

FILE: 

math.c 

DESCRIPTION: 

Fast  3-D  hypotenuse  routine. 
PARAMETERS: 
a,b,c 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 
None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 

Returns  sqrt  of  a*a  +  b*b  +  c*c. 
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ROUTINE: 

inner_prod 

FILE: 

math.c 

DESCRIPTION: 

Returns  the  inner  product  of  2  vectors. 
PARAMETERS: 

vector  1,  vector2 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 

Although  .similar  to  dot,  the  GD  version  uses 
type  double  instead  of  float. 


A-37 


ROUTINE: 

initgraphics 

DESCRIPTION: 

Initializes  the  graphics  window  in  preparation  for  displaying  the 
different  STI  formats.  Also  queues  up  the  different  devices  that 
will  be  used  by  the  controlO  routine.  Some  of  the  parameters  to 
the  graphics  calls  are  hardwired  to  the  vgx’s  #defines,  but  should 
be  set  according  to  getgdescO  calls. 


PARAMETERS: 
name  i 
mode  i 


name  of  window  to  be  opened 
if  mode  =  NTSC,  sets  up  the  graphics  for 
an  ntsc  signal,  any  other  value  is  the  full 
screen  of  the  standard  60  HZ  monitor 


GLOBALS  ACCESSED: 

aspect  i/o  aspect  ratio  of  screen  x  to  screen  y 
fov  i/o  field  of  view  in  screen  y  direction 

USER  ROUTINES  CALLED: 
initlight 
initmap 


GD  ROUTINES  CALLED: 
make  chars 


**  REVISION  HISTORY 

**  0.0  dcrobohm  92/09  original 

*1 
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/* 

**  ROUTINE: 

**  initlight 

**  DESCRIPTION: 

**  Sets  up  the  lighting  model  for  doing  light  shaded  polygons.  The 

**  model,  light,  and  material  are  defined  and  bound. 

**  PARAMETERS: 

**  None 
** 

**  GLOBALS  ACCESSED: 


3|c;ic 

matl 

i 

material  used  for  lighting  calculations 

Utl 

i 

light  used  for  lighting  cdculations 

** 

** 

modi 

i 

model  used  for  Ughdng  calculations 

**  USER  ROUTINES  CALLED: 

**  None 
** 


**  REVISION  HISTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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/* 

♦*  ROUTINE: 

**  initmap 

**  DESCRIPTION: 

**  Initializes  an  elevation  based  color  map  of  the  format  needed  to 
**  pass  to  the  cpack  call  (i.e.,  OxAABBGGRR).  Not  space  efficient, 
**  because  it  sets  a  long  for  each  integral  elevation  from  -100  feet 

**  to  4400  feet,  but  it  eliminates  the  need  to  do  some  calculations 

**  at  run  time.  Try  to  vary  the  colors  to  provide  some  texturing. 


**  PARAMETERS: 

**  None 

**  GLOBALS  ACCESSED: 


sti_colrmap 


long  colormap  of  format  OxBBGGRR 


**  USER  ROUTINES  CALLED: 
**  None 

afc* 


**  REVISION  fflSTORY 
**  0.0  dcrobohm  92/09  original 

*/ 
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/♦ 

*♦  ROUTINE: 

**  initmat 
** 

**  DESCRIPTION: 

**  Takes  a  4  X  4  double  array  and  initializes  it  to  an  identity  matrix. 

** 

**  PARAMETERS: 

**  mat[4][4]  o  matrix  to  be  initialized 

9(caie 

**  GLOBALS  ACCESSED: 

**  None 
** 

**  USER  ROUTINES  CALLED: 

**  None 
** 

**  REVISION  fflSTORY 

**  0.0  dcrobohm  92/09  original 

*1 
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/* 

**  ROUTINE; 

**  loadblcxjk 

Kc* 

**  DESCRIPTION: 

**  Loads  a  block  of  data  from  the  file  pointed  to  by  fp  into  the  array 

**  block.  If  either  the  row  or  the  column  does  not  lie  within  the 
**  terrain  file,  the  array  is  filled  with  zeros.  Routine  is  based 
**  on  CD’s  Load_Terrain_Block.  Remember,  the  blocks  are  stored  in 
**  column  major  order  within  the  file,  and  the  data  is  stored  column 
**  major  withm  the  block. 


**  PARAMETERS: 

**  fp  i  file  poir 

**  row  i  desired  1 

**  col  i  desired  1 

**  block  o  filled  wi 

**  GLOBALS  ACCESSED: 

**  None 

** 

**  USER  ROUTINES  CALLED: 

**  None 

** 


file  pointer  to  opened  terrain  file  in  GD  format 
desired  block  row  in  file  pointed  to  by  ^ 
desired  block  col  in  file  pointed  to  by  fp 
filled  with  elevation  posts  fi-om  the  block 


**  REVISION  fflSTORY 

**  0.0  dcrobohm  92/09  original 

*/ 
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/★ 

**  ROUTINE: 

**  loadtile 

**  DESCRIPTION: 

**  Loads  the  appropriate  tile,  block  by  block,  into  memory,  sets  the 
**  appropriate  fields  of  the  structure,  and  computes  the  smface 

**  normals  of  the  terrain  at  each  elevation  post. 

** 

**  Loadtile  was  written  to  be  spawned  as  a  separate  process  with  the 
**  sproc  call.  There  are  no  formal  parameters,  but  it  communicates 
**  with  the  parent  process  through  several  fields  of  the  array  tiles. 

**  A  “double  buffered”  approach  has  been  adopted  to  avoid  the  problems 
**  of  multiple  processes  concurrently  accessing  and  modifying  the  same 
**  memory  locations.  The  parent  process  will  use  one  buffer  while 
**  loadtile  will  modify  the  other  buffer  until  processing  is  completed, 

**  at  which  time  the  buffers  are  “swapped”. 

** 

**  Loadtile  will  wait  until  the  mpflag  of  the  current  buffer  is  set  to 
**  MP_CPUSTART.  Once  it  is  told  to  start,  it  will  get  the  center  row 

**  and  column  in  blocks  from  the  blkrow  and  blkcol  fields.  Then  it 

**  reads  data  and  computes  normals.  When  all  processing  is  done,  it 
**  sets  mpflag  to  MP_CPUDONE,  signalling  the  parent  process  that  the 
**  tile  is  loaded  and  ready  for  use.  It  then  “swaps”  buffers  to  wait 
**  for  another  MP  CPUSTART. 


**  PARAMETERS: 

**  None 

**  GLOBALS  ACCESSED: 

**  tiles  i/o  accesses  mpflag,  blkrow,  and  blkcol  fields  of 
**  the  cuirent  buffer  for  next  tile  to  be  loaded, 

**  and  loads  the  elevation  data  into  the  elev  field. 

**  USER  ROUTINES  CALLED: 

**  cross 

**  loadblock 

**  normalize 

**  pp2v 


**  REVISION  fflSTORY 
**  0.0  dc  robohm  92/09  original 

*/ 
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ROUTINE: 
main  (STI) 

DESCRIPTION: 

The  executive  of  the  SH  program,  opens  the  DTED  file,  opens  the 
ethemet  connection,  launches  the  tile  loader  as  a  separate  process, 
initializes  the  graphics,  and  passes  control  to  the  controller. 

On  return  from  the  controller,  resets  the  graphics,  kills  the 
loadtile  process,  closes  the  ethemet  connection,  and  closes  the 
DTED  file. 


PARAMETERS: 
filename  i 
-ntsc  i 

-small  i 

-ethemet  i 


name  of  the  blocked  DTED  file.  (CD's  format) 
optional,  sets  up  the  run  in  ntsc  mode, 
optional,  displays  in  an  ntsc  sized  window 
optional,  enables  ethemet 


GLOBALS  ACCESSED: 
None 


USER  ROUTINES  CALLED: 


closedmafile 

control 

initgraphics 

gridupdate 

loadtile 

opendmafile 

resetgraphics 


(spawned  as  a  separate  process) 
(pawned  as  a  separate  process) 


GD  ROUTINES  CALLED: 
udpbclose 
udpbopen 

REVISION  fflSTORY 
0.0  dc  robohm 

0.1  dc  robohm 


92/09  original 

92/09  added  ethemet  initialization. 


ROUTINE: 

make_chars 

FILE: 

grfx 

DESCRIPTION: 

Creates  the  graphical  text  font  used  by  the  HMD  as  objects. 
PARAMETERS: 

None 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  HISTORY: 

0.0  GD  original. 

NOTES: 
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/* 

**  ROUTINE: 

**  managememory 
** 


**  DESCRIPTION: 

**  Does  the  memory  management  job  for  the  STI  program.  As  input  it 
**  takes  the  current  position  in  feet,  converts  it  into  file  blocks 

**  (according  to  CD’s  format),  and  determines  if  a  new  tile  must  be 

**  loaded  into  memory.  If  a  new  tile  needs  to  be  loaded,  it  calls 
**  loadtile  indirectly  through  the  mpflag,  blkrow,  and  blkcol  fields 
**  of  the  current  buffer  of  die  tiles  array. 


** 

** 

** 

** 

** 

** 

** 


This  routine  always  looks  at  the  same  buffer  of  the  tiles  array 
as  loadtile,  so  it  can  tell  loadtile  to  start  reading  in  a  new 
tile,  and  also  to  catch  the  signal  from  loadtile  Aat  it  has 
completed  the  load.  On  the  first  invocation,  managememory  must 
call  loadtile  and  wait  until  loadtile  has  finished  so  the  global 
pointer  tile  can  point  to  some  real  data.  After  the  first  call, 
we  never  wait  for  loadtile.  We  simply  check  to  see  if  it  has 
finished  with  the  current  load,  and  if  it  has  do  two  things: 
first  make  sure  tile  points  to  the  current  buffer  (which  contains 
the  most  recently  loaded  data),  and  second  check  to  see  if  we  need 
to  start  loading  another  tile.  If  another  tile  is  needed,  “swap” 
buffers  and  give  loadtile  the  appropiate  parameters  in  the  tties 
array.  Let  loadtile  do  its  thing  while  managememory  returns 
control  to  the  calling  routine.  If  loadtile  wasn’t  finished  with 
its  current  tile,  simply  remrn  control  to  the  calling  routine. 


**  PARAMETERS: 

__  ? 


** 


i 


east  -  west  position  in  feet 
north  -  souA  position  in  feet 


**  GLOBALS  ACCESSED: 


** 

** 


tile 

tiles 


o  pointer  to  the  current  tiles  buffer, 
i/o  mpflag,  blkrow,  and  blkcol  fields  provide 
communication  with  the  loadtile  process. 


**  USER  ROUTINES  CALLED: 
**  None 


**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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/* 

**  ROUTINE: 

**  mpymat 

**  DESCRIPTION: 

**  Performs  matrix  multiplication  c  =  a  *  b.  originally  set  a 
**  temporary  matrix  to  a  *  b,  then  sets  c  =  tmp,  in  case  c  is 
**  the  same  matrix  as  a  or  b. 


PARAMETERS: 

** 

a[4][4]  i 

a  matrix 

b[4][4]  i 

b  matrix 

c[4][4]  0 

result  of  a  *  b 

**  GLOBALS  ACCESSED: 

**  None 

**  USER  ROUTINES  CALLED: 

**  None 
** 

**  REVISION  fflSTORY 
**  0.0  dcrobohm  92/09  original 

*/ 
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/* 

**  ROUTINE: 

**  normalize 

**  DESCRIPTION: 

**  Normalize  a  vector  to  unit  length.  Replaces  the  original  vector 
**  with  the  unitized  one. 

**  PARAMETERS: 

**  V  i/o  vector  to  be  normalized 

** 

**  GLOBALS  ACCESSED: 

**  None 

**  USER  ROUTINES  CALLED: 

**  None 

**  REVISION  fflSTORY 
**  0.0  dcrobohm  92/09  original 

*/ 
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ROUTINE: 

normalize_vec 

FILE: 

math.c 

DESCRIPTION: 

Normalizes  a  vector  to  unit  length. 

PARAMETERS: 

vector 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 
hypotS 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 

Although  similar  to  normalize,  the  GD  version  uses  type  double  instead  of  float. 
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**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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ROUTINE: 

outer_prod 

FILE: 

math.c 

DESCRIPTION: 

Computes  the  outer  product  of  2  vectors. 
PARAMETERS: 

vector  1,  vector!,  result 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  HISTORY: 

0.0  GD  original. 

NOTES: 

Although  similar  to  cross,  the  GD  version  uses 
type  double  instead  of  float. 
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/* 

**  ROUTINE: 

**  pp2v 

**  DESCRIPTION: 

**  Determines  the  vector  between  two  points. 

**  PARAMETERS: 

**  pi  i  point  1 

**  p2  i  point  2 

**  V  o  vector  from  point  1  to  point  2 

** 

**  GLOBALS  ACCESSED: 

**  None 

**  USER  ROUTINES  CALLED: 

**  None 

**  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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ROUTINE: 

Radar_alt 

FILE: 

ethemet.c 

DESCRIPTION: 

Radar_alt  determines  1)  if  the  radar  altimeter  CAN 
determine  the  radar  altitude  and,  if  so, 

2)  what  the  radar  altitude  is. 

PARAMETERS: 

os 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 
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ROUTINE: 

rcv_ethemet 

FILE: 

ethemet.c 

DESCRIPTION: 

Rcv_ethemet  picks  up  and  decodes  pakets  sent  to  the 
open  socket  Only  packets  with  the  coirect  id  code,  i.e. 
one  =  thisship  wU  be  recognized.  There  are  3  data  packets 
that  are  used  by  the  STI  system:  TERRAIN  type,  which  include 
such  things  as  the  terrain  file  to  load,  the  x  coordinate 
of  the  western  edge  of  the  database,  the  y  coordinate  of  the 
southern  edge  of  the  database,  and  the  STI  parameters,  and 
2)  the  TARGET  type,  which  reads  a  packet  of  etherown  type 
into  a  structure  of  target_type.  (The  first  portion  of 
target_type  is  identicd  to  etherown_type).  Angle_computations 
then  expands  the  data  to  fill  the  rest  of  the  target 
structure. 

PARAMETERS: 

None 

GLOBALS  ACCESSED: 

os  terrparm  gc_steering  wind  planetime  netfd  thisship  terrain_name 
USER  ROUTINES  CALLED: 
getelev 
Radar_alt 

Angle_computations 
REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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/* 

**  ROUTINE: 

**  render 

** 

**  DESCRIPTION: 

**  Takes  as  input,  the  desired  format  to  be  drawn,  and  calls  the 
**  appropriate  routines  to  display  that  format.  The  symbolic 
**  constants  for  the  formats  are  defined  in  def.h. 


**  PARAMETERS: 

**  format  i  the  format  of  the  terrain  display 


**  GLOBALS  ACCESSED: 


fat  i 

hidden  i 

position  i 


flag  to  determine  if  lines  are  1  or  2  pixels 
flag  to  determine  if  we  need  to  do  hidden 
point/line  removal 

to  get  height  AGL  for  progressive  format 


** 


**  USER  ROUTINES  CALLED: 


** 

Draw_dma _grid 

Draw_dma_ridge 

** 

drawgradient 

aicale 

drawmesh 

drawpoints 

drawpolys 

drawsquares 

** 

hide 

**  REVISION  fflSTORY 

♦*  0.0  dc  robohm  92/09  original 

*/ 
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ROUTINE: 

resetgraphics 

DESCRIPTION: 

Resets  the  graphics  to  a  reasonable  state  when  the  simulation  is 
completed. 

PARAMETERS: 

mode  i  if  mode  ==  NTSC,  an  ntsc  signal  was  being 

output,  so  it  must  be  reset  to  the  standard 
60  HZ  monitor 

GLOBALS  ACCESSED: 

None 


USER  ROUTINES  CALLED: 
None 


**  REVISION  HISTORY 

**  0.0  dc  Tobohm  92/09  original 

*/ 
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ROUTINE: 

Ridgeline_extract 

FILE: 

GDrender.c 

DESCRIPTION: 

Ridgeline  extract  is  very  similar  to  Get_high_ 
intersections,  but  instead  of  storing  the  point  representing  the 
highest  visual  angle  to  date  based  on  crossing  some  criteria, 
Ridgeline  extract  stores  the  point  whenever  a  ridgeline  is  crossed, 
that  is,  whenever  the  visual  angle  to  the  projected  point  is  less 
than  the  angle  to  the  previous  point  Lo^c  then  tries  to  correlate 
the  point  with  a  ridgepoint  from  the  previous  projection;  if  one  is 
found,  the  point  is  added  to  its  array;  else  a  new  array  is  started. 
If,  after  the  projection  reaches  “far”  there  is  an  array  of  points 
which  was  NOT  added  to,  it  is  “closed”  and  the  remainder  of  the 
array  made  available  for  re-use.  These  points  are  stored  in  the 
same  h  and  vl  arrays  used  by  Get_high_intersections,  allowing  up 
to  8  separate  ridges  along  one  angle. 

PARAMETERS: 

point  “the  starting  point  of  the  projection, 
los  --unit  vector  defining  line  of  sight  to  look  down, 
far  —for  4th  horizontal  line 
vdf  -proportion  of  the  projected  line  in  the 
—direction  of  the  LOS. 
h  -array  holding  the  horizontal  line  points. 

V  -array  holding  the  vertical  line  points, 
nph  -number  of  points  in  the  horizontal  line  arrays, 
npv  —number  of  points  in  the  vertical  line  arrays. 
last_hratio  -last  visual  anlel  from  previous  projection. 
last_vratio  -same  for  the  vl  array. 

GLOBALS  ACCESSED: 
toggle 

USER  ROUTINES  CALLED: 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

rotate_vector 

FILE: 

math.c 

DESCRIPTION: 

Rotates  a  vector  using  passed  matrix. 
PARAMETERS: 

vector,  rot_mat 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 

See  set_rotation  above. 


/* 

**  ROUTINE: 

**  rotmat 
** 

**  DESCRIPTION: 

**  Rotates  the  matrix  by  a  radians  around  the  given  axis.  This  routine 

**  multiplies  the  matrices  in  the  same  order  as  SGI’s  rot()  call. 

** 

**  PARAMETERS: 

**  a  i  angle  (in  radians)  to  rotate  the  matrix  by 

**  axis  i  axis  aWt  which  the  matrix  is  to  be  rotated 

**  mat[4][4]  o  matrix  to  be  initialized 

** 

**  GLOBALS  ACCESSED: 

**  None 

** 

**  USER  ROUTINES  CALLED: 

**  initmat 

**  mpymat 

*♦  REVISION  fflSTORY 

**  0.0  dc  robohm  92/09  original 

*/ 
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ROUTINE: 

rotvec2d 

FILE: 

GDrender.c 

DESCRIPTION: 

Rotvec2d  is  a  2  dimensional  version  of  rotate_vector. 
Since  it  assumes  rotation  around  “z”,  and  only  affects  the 
xy  of  the  vector,  it  can  be  optimized  for  2d  use. 

PARAMETERS: 
ang,  vec 

GLOBALS  ACCESSED: 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

set_rotation 

FILE: 

math.c 

DESCRIPTION: 

Sets  up  the  matrix  for  vector  rotation  using  rotate_vector. 
PARAMETERS: 

u,  angle,  rot_mat 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 

Sets  up  the  matrix  to  rotate  around  unit  vector  u  by  angle 
radians  and  returns  it  in  rot_mat.  Better  than  rotating 
directly,  since  frequently  several  vectors  will  need  to  be 
rotated  identically. 
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ROUTINE: 

Setup_dma_grid 

FILE: 

GDrender.c 

DESCRIPTION: 

Depending  on  whether  the  STI  format  is  ortho  or  a  ridgeline 

extraction  system,  calls  Get_high_intersections  or 

Ridgeline_extract  for  angles  off  the  current  line  of 

sight,  extracting  the  information  needed  to  draw  the 

lines  representing  the  format  and  storing  them  in  the 

h,  vr,  and  vl  arrays.  When  the  array  is  through  updating,  flips 

toggle  to  allow  access  to  the  new  data. 

PARAMETERS: 

os  eye_ul  newar  far  format 
GLOBALS  ACCESSED: 

h,  vl,  vr,  nph,  npvr,  npvl,  toggle 
USER  ROUTINES  CALLED: 

Get_high_intersections 
Ridgeline_extract 
REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

udpbread 

FILE: 

udpb.c 

DESCRIPTION: 

Reads  a  packet  from  the  open  socket. 
PARAMETERS: 

netfd  buffer  len 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 
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ROUTINE: 

udpbopen 

FILE: 

udpb.c 

DESCRIPTION: 

Opens  the  socket  for  the  UDP  protocol  ethemet  system.  The 
socket  opened  must  be  defined  in  the  /etc/services  file  of  the 
system. 

PARAMETERS: 

service  (string:  name  of  the  service). 

GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

Getbroadcast 
Gethostaddr 
REVISION  HISTORY: 

0.0  GD  original, 

NOTES: 

Getbroadcast  and  Gethostaddr  were  modified  from  the  code 
provided  by  Silicon  Graphics  in  the 
/usr/people/4Dgifts/examples/network  directory. 
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ROUTINE: 

udpclose 

FILE: 

udpb.c 

DESCRIPTION: 

Closes  the  open  socket. 
PARAMETERS: 
netfd 

GLOBALS  ACCESSED: 
None 

USER  ROUTINES  CALLED: 
None 

REVISION  fflSTORY: 

0.0  GD  original. 

NOTES: 


ROUTINE: 

udpwrite 

FILE: 

udpb.c 

DESCRIPTION: 

Writes  a  packet  to  the  open  socket. 
PARAMETERS: 

netfd  buffer  len 
GLOBALS  ACCESSED: 

None 

USER  ROUTINES  CALLED: 

None 

REVISION  HISTORY: 

0.0  GD  original. 

NOTES: 


APPENDIX  B 

Concept  Paper 


INTRODUCTION 


The  objective  of  this  effort  is  to  evaluate  the  utility  of  a  synthetically  derived  terrain 
image  on  a  pilot’s  helmet-mounted  display  (HMD)  from  stored  digital  terrain  data  for  the 
purpose  of  improved  Situation  Awareness. 

In  order  to  accomplish  the  stated  objective,  it  will  be  necessary  to  consider  the  technology 
issues  associated  with  the  display  of  synthetic  terrain  imagery  (STI)  formats.  In  addition, 
considerable  effort  is  required  (design  and  evaluation)  to  assure  Aat  the  pilot  can  easily 
interpret  the  terrain  formats  while  flying  high  speed  tactical  missions. 

The  purpose  of  this  Concept  Paper  is  to  document  the  rationale  for  the  approach  taken  by 
the  Honeywell/General  Dynamics  team  in  the  pursuit  of  program  goals. 

The  remainder  of  this  brief  is  organized  as  follows: 


Mission  Requirements: 
User  Needs: 

Format  Concepts: 

PVI  Analysis: 

Recommended  Approach: 


Outlines  the  mission  needs  that  impact  the  terrain  format  design 
Review  STI  issues  associated  with  spatial  situation  awareness 
Presentation  of  the  STI  formats  developed  for  testing 
Discussion  of  the  integration  of  STI  formats  with  conventional 
alphanumeric  symbology 

Outlines  the  STI  formats  that  will  be  taken  into  testing 


MISSION  REQUIREMENTS 


The  capability  to  employ  day  tactics  on  night  missions  has  always  been  recognized  as 
extremely  beneficial,  but  only  recently  has  the  technology  evolved  to  the  point  where  this 
is  now  becoming  feasible. 

The  operational  requirements  for  the  night  close  air  suppon/battlefield  air  interdiction 
(CAS/BAI)  mission  remain  the  same  as  for  day  missions.  For  example,  the  aircraft  must 
penetrate  the  threat  environment  and  navigate  to  the  target  area.  Once  there,  the  pilot 
must  acquire  the  target,  properly  maneuver  the  aircraft  to  deliver  selected  weapons,  and 
safely  egress. 

An  effective  night  attack  system  would  allow  the  pilot  to  ingress  the  target  area  at  low 
altitude  and  then  use  a  delivery  mode  such  as  Continuously  Computed  Impact  Point 
(CCIP)  for  weapons  employment.  This  delivery  mode,  which  r^uires  the  pilot  to 
visually  acquire  the  target,  is  difficult  enough  during  day  operations  but  nearly  impossible 
at  night  without  an  effective  night  attack  system.  Egress  from  the  target  area  will  again 
be  at  low  altitude  to  minimize  detection  by  enemy  threats. 


An  effective  night  attack  system  should  allow  the  pilot  to  utilize  tactics  simil^  to  those 
used  during  the  day.  For  example,  a  conventional  daytime  CAS  scenario  begins  with  a 
low-level  ingress  to  a  contact  point  to  receive  target  information  from  a  Forward  Air 
Controller  (FAC).  This  target  information  consists  of  a  “9-line  briefing”  which  includes: 


•  location  of  IP 

•  heading  and  distance  to  target 

•  target  location 
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•  target  elevation 

•  target  description 

•  how  the  target  will  be  identified  (smoke,  laser,  etc.) 

•  location  of  friendly  troops 

•  threat  location 

•  egress  direction 

The  attack  aircraft  proceeds  to  the  IP  to  attack  the  assigned  target.  Ingress  to  the  target 
area  will  be  at  low  altitude  taking  advantage  of  terrain  features.  Radio  emissions  are 
minimized  to  mask  the  intended  approach  to  the  target. 

Since  ingress  altitude  is  usually  low  to  avoid  detection,  a  pop-up  maneuver  is  required  to 
aid  in  target  acquisition.  At  four  to  five  nautical  miles  from  the  target,  a  3  to  4G  tirni  is 
executed  to  offset  the  target  30-40  degrees  left  or  right  of  the  nose.  An  offset  attack  is 
used  to  allow  the  pilot  more  time  for  target  acquisition  and  better  control  of  the  apex 
altitude  during  the  pop,  based  on  target/aircraft  attack  geometry.  Weapon  release  is 
accomplished  in  a  low  angle  dive  delivery  followed  immediately  by  a  hard  turn  to  avoid 
the  weapon  fragmentation  pattern.  Chaff/flare  expendables  and  hard  maneuvering  are 
also  required  after  weapon  release  to  defeat  enemy  defenses. 

To  provide  mutual  support  and  increase  the  number  of  bombs  on  target,  a  formation  of 
two  aircraft  will  norm^ly  be  employed.  When  two  aircraft  are  used  to  attack  a  target, 
each  member  of  the  formation  must  have  knowledge  of  the  other  aircraft’s  position 
during  the  low  altitude  ingress,  target  attack,  and  egress.  The  wingman’s  position  during 
the  ingress  can  be  from  line  abreast  to  as  much  as  &  degrees  aft  of  the  le^er  based  on 
the  threat  and  surrounding  terrain.  When  the  leader  offsets,  the  wingman  will  offset  to 
gain  separation  in  both  attack  heading  and  time  from  the  leader.  This  will  normally 
require  the  wingman  to  delay  his  pull-up  or  arc  the  target  at  3-4  nautical  miles  prior  to 
beginning  his  pop-up  maneuver.  This  separation  varies  the  attack  axis  and  helps  the 
wingman  avoid  tibe  fragmentation  of  the  leader’s  weapons.  The  egress  maneuvers  are 
similar  with  the  intent  of  providing  mutual  support  as  quickly  as  possible  coming  off  the 
target. 

For  guided  munitions  such  as  Maverick  (AGM-65)  missiles,  the  attack  profile  would  be 
similar  to  those  previously  described  except  the  range  for  offset/arcing  of  the  target  area 
would  be  greater  and  the  altitude  in  the  climb  would  be  the  minimum  required  to  acquire 
the  target  Since  the  field-of-view  of  guided  niunitions  is  very  narrow,  it  is  critical  that 
the  target  be  present  in  the  weapons  field-of-view  for  manual  designation,  or 
automatically  locked-on  when  line-of-sight  is  established  for  a  successful  first  pass 
attack.  To  minimize  closure  on  the  target,  and  hence  maximize  stand-off  range,  an  offset 
attack  near  the  weapons  azimuth  lock-on  limits  should  be  employed.  This  will  allow 
multiple  weapons  to  be  employed  at  targets  in  close  proximity,  minimize  the  total  time 
that  the  aircr^t  is  exposed  to  surface-to-air  threats,  and  keep  the  aircraft  at  the  greatest 
standoff  distance  from  the  target. 

To  successfully  accomplish  the  above  mission  at  night,  the  pilot  must  be  able  to  acquire 
the  intended  target  in  sufficient  time  to  complete  the  attack  profile.  For  employing 
conventional  weapons,  a  night  vision  system  must  provide  sufficient  resolution  to  have 
three  miles  visibility  in  most  conditions  and  provide  sufficient  warning  of  obstacles  and 
cultural  features.  During  the  attack  phase,  the  system  must  have  sufficient  resolution  to 
locate  a  target  at  ranges  of  4  to  5  nautical  miles  and  provide  target  recognition  prior  to 
weapon  release.  Positive  target  acquisition  in  narrow  field-of-view  must  occur  between  2 
to  3  nautical  miles  to  allow  8  to  10  seconds  to  position  the  aircraft  for  weapons  delivery. 
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Weapons  release  will  occur  at  ranges  slightly  less  than  1  nautical  mile  from  dive  angles 
of  5  to  10  degrees. 

Azimuth  requirements  for  utilizing  a  Head-Steered  Infra  Red  (HSIR)  sensor  will  exceed 
60  degrees  during  several  segments  of  the  attack  profile.  For  example,  during  target 
ingress,  the  wingman  could  require  azimuth  angles  exceeding  90-degrees  to  determine  the 
leader’s  position.  The  wingman’s  azimuth  to  the  target  may  exceed  60-degrees  while 
maneuvering  to  retain  the  appropriate  interval  and  spacing  from  the  leader  by  dela^ng 
the  pull-up  in  the  target  area.  The  leader  may  also  require  more  than  90-degree  azimuth 
coverage  to  acquire  the  wingman’s  position  during  the  egress  for  mutual  support  and 
rejoin. 

In  addition  to  an  effective  night  vision  system,  there  are  two  other  key  elements  needed  to 
ease  pilot  workload  during  night  operations — accurate  navigation  and  positive  target 
acquisition.  Accurate  navigation  can  be  provided  by  incorporating  a  Digital  Terrain 
System  (DTS)  which  will  reduce  the  time  spent  on  navigation.  The  DTS  can  also  provide 
covert  terrain-following  (TF)  capability,  an  all  attitude  predictive  ground  proximity 
warning  system,  and  passive  ranging.  TTiis  system  will  also  form  the  basis  for  a  Synthetic 
Terrain  Imaging  system. 

An  effective  data  link  system  can  ease  the  target  acquisition  problem.  This  system  would 
use  the  UHF  or  VHF  radio  to  receive  data  link  information  from  either  a  ^und  observer 
or  similarly  equipped  fixed  wing/rotary  aircraft.  Using  a  data  link  transmission,  the  FAC 
passes  the  “9-line  brief’  directly  to  the  Fire  Control  Computer  and  graphically  displays  it 
to  the  F- 16  pilot.  The  pilot  now  has  IP/target  location,  desired  run-in  heading,  target 
type,  and  location  of  fnendlies  displayed  without  the  need  for  lengthy  voice 
communications  and  subsequent  manual  entry  of  targeting  data. 

USER  NEEDS 

Goals  for  the  terrain  images  are:  formats  sufficient  for  terrain  awareness  during  high 
speed  low  altitude  flight,  day  or  night,  when  the  horizon  is  indistinct  or  obscur^,  and 
height  above  the  surface  cannot  be  judged  visually.  Display  formats  should  provide 
terrain  awareness  over  any  surface.  The  formats  should  project  minimal  imagery 
necessary  to  provide  the  pilot  with  sufficient  visual  cues  to  determine  approximate  height 
above  the  surface,  approximate  distance  to  points  on  the  surface,  the  motion  of  the 
aircraft  relative  to  the  surface,  and,  the  relative  proximity,  shape,  and  size  of  terrain 
features.  The  terrain  image  needs  to  be  detailed  only  enough  to  provide  awareness  of 
general  terrain  features.  The  pilot  needs  to  perceive  the  terrain,  but  not  have  the  image 
block  or  interfere  with  his  view  of  the  outside  world  or  the  cockpit.  The  image  should  be 
available  in  the  full  field  of  view  of  the  HMD,  and  must  be  available  not  only  in  the 
direction  of  flight,  but  off-axis  enough  to  permit  aggressive,  high-G  maneuvering  for 
terrain  masking  during  the  navigation  phases  of  flight,  as  well  as  during  offensive  and 
defensive  maneuvering.  Enhancements  of  the  raw  terrain  image  with  other  features  to 
add  to  the  pilot’s  total  situation  awareness  should  be  explored.  The  design  effort  must 
involve  the  consideration  of  pilot  visual  perception,  and  other  human  factors. 

The  intent  of  the  STI  for  HMD  program  is  to  provide  the  pilot  with  earth  references  to 
reduce  the  possibility  of  disorientation,  particularly  with  respect  to  sky/ground 
orientation.  In  order  to  achieve  the  desired  program  goal,  “synthetically”  derived  terrain 
depiction’s  will  be  rendered  on  the  HMD  to  show  the  relative  position  of  the  earth 
(spatial  relationship  to  aircraft  and  proxmitiy)  and  gross  features  of  the  terrain. 
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It  is  useful  to  examine  how  STI  formats  can  aid  in  the  fulfillment  of  mission 
requirements.  The  following  Table  identifies  the  elements  of  the  STI  system  (including 
Off-Axis  Attitude  Awareness  Symbology)  that  aid  the  pilot  in  accomplishing  the  mission 
requirements. 


STI  aids  to  Mission  Requirements 

It  has  long  been  known  that  without  reference  to  outside  cues  pilots  will  quickly  become 
disorient^.  Jarvi  (1981),  in  a  report  investigating  spatial  disorientation  in  F-15  pilots, 
compiled  a  list  of  factors  that  contribute  to  disorientation,  including: 

•  Autokinesis 

•  Fascination 

•  Target  Hypnosis 

•  illusory  Effects  Due  to  Inadequate  Stimuli 

•  Improper  Grouping  of  Lights  at  Night 

•  Illusions  of  Relative  Motion 

•  Illusory  Horizons 

It  is  the  intent  of  the  current  program  to  overcome  visual  factors  that  contribute  to  spatial 
disorientation  by  rendering  a  synthetic  image  of  terrain  (or  water)  so  the  pilot  has  a  clear, 
unambiguous,  indication  of  orientation  with  respect  to  the  earth.  A  reasonable  concern 
with  the  current  project  is  the  addition  of  symbology  to  a  display  which  already  has  a 
number  of  discrete  elements  for  fear  overwhelming  the  pilot.  To  state  this  more  directly, 
the  pilot  may  not  have  the  attentional  resources  required  to  interpret  the  STI.  Recently 
Weinstein  and  Wickens  (1992)  have  shown  that  an  “ecologically”  valid  display  (contact 
analog  of  the  out-the- window  visual  scene)  allowed  for  the  most  efficient  time-sharing. 
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FORMAT  CONCEPTS 
Helmet-Mounted  Display  Symbology 

The  STI  formats  will  be  overlaid  with  the  HMD  symbol  set  that  was  developed  by 
General  Dynamics  during  the  “Night  Attack  Program  Pilot-Vehicle  Interface  Study.” 
The  HMD  symbol  set  is  shown  below: 

Original  HMD  Expanded  HMD 

Symbology  Set  Symbol  Set 


Boresight  Cross 

-h 

Centercross 

1 

"1 

Horizon  Line 

A 

Up  Pointer 

If 

A/G  Target  Designator 

□ 

i 

Target  Locator  Line 

4 

G 

CCIP  Reticle 

+ 

Bomb  Fall  Line  with 

Solution  Cues 

X 

Breakaway  Cross 

Flight  Path  Market 

1 _ I 

Pull-up  Anticipation  Cue 

FLIR  Polarity 

BH 

Airspeed 

350  C 

Altitude 

R  1,000 

Warning 

WARN 

Fuel 

FUEL 

FLIR  Overheat 

OVHT 

LOW  error 

LAG 

FLIR  Gain 

G03 

FLIR  Level 

L45 

NFOV  Comers* 

n 

L  J 

*  NFOV  corners  are  generated  by  the 


TF  Cue 

Angle  of  Attack  (ADA)  Error  Bracket 

Pitch  Scale 

Heading  Scale 

Radar  Thermometer  Scale 


Off-Axis  TF  Cue  and  FPM 
Smaller  Centercross 
TF  Warnings 

TERPROM  Status  Window 
FLIR  and  are  embedded  in  the  raster  picture 


10 1  |10 

5l  I  5 


5 1 . i  5 

.  y  i'  .  . 

22  23  24 


-15 

^10 


OBST 
LOFT 
NO  TURN 

K001 

030D03 


0910911-09 


An  example  of  the  “Night  Attack”  symbology  in  the  HMD  is  shown  below. 
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Svmbol  C910911-4 

Synthetic  Terrain  Imagery  Formats 

It  is  important  to  identify  the  elements  of  the  terrain  image  that  aid  in  the  determination 
of  spatial  orientation  to  assure  that  the  STI  formats  contain  these  elements.  Weinstein 
and  Wickens  (1992)  have  provided  a  concise  review  of  the  format  characteristics  of  a 
contact  analog  display: 

Optical  Flow:  The  accelerating  flow  of  texture  down  the  visual  field 
Splay:  Parallel  lines  with  a  common  vanishing  point 

Compression:  The  foreshortening  of  a  projection  as  it  is  slanted  away  from  the 
frontal  plane 

A  key  element  in  the  presentation  of  the  STI  presentation  is  the  frame  of  reference  for  the 
rendering  of  the  terrain  image,  it  can  either  be  geographically  fixed  or  aircraft  centered. 

If  the  format  is  observer  centered  then  the  presentation  will  ^ways  have  the  cockpit  as 
the  center  of  orientation  (a  bit  like  the  early,  Ptolemy,  view  of  the  Universe).  The 
geographically  fixed  presentation  requires  that  the  format  elements  (e.g.,  lines,  points  of 
light,  tUes)  be  linked  to  the  ground. 
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The  first  two  formats,  Ridgelines  and  the  Optical  Expansion  Gradient,  are  aircraft 
centered  formats.  The  remaining  formats  are  geographically  fixed. 

Ridgelines  — 


C92057-17 


This  is  format  an  outgrowth  of  the  work  Honeywell  conducted  on  the  Quiet  Knight 
program.  Discrete  range-bins  from  the  aircraft  are  sampled.  Within  each  range-bin  the 
highest  points  are  identified  and  a  line  is  drawn  laterally  connecting  the  peaks. 

Optical  Expansion  Gradient — 


0620574-01 


This  approach  is  an  analog  of  the  splay  lines  in  an  attitude  direction  indicator  (ADI).  The 
implementation  of  this  approach,  similar  to  Ridgelines,  requires  an  observer  center^  (as 
opposed  to  a  geographically  fixed)  approach.  'Hus  is  because  the  vanishing  point  must 
always  be  centered  on  the  flight  path  vector  of  the  aircraft.  The  highest  points,  at  a  fixed 
spacing,  are  then  represented  by  perturbations  in  the  splay  lines  of  die  gradient. 
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Contact  Analog  Grid  — 


C920574O3 


The  geographically  fixed  presentation  scheme  looks  as  though  a  large  net  were  laid 
across  the  earth.  The  grid  is  deformed  by  topographic  surface  features. 

Contact  Analog  Grid  with  Tiles  — 


CS20574-03 


This  presentation  scheme  is  identical  to  the  Contact  Analog  Grid  with  the  addition  of 
Tiles  in  the  open  area  within  each  grid.  The  tiles  are  oriented  perpendicular  to  the  surface 
normal  of  the  local  square. 
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Tiles  — 


This  presentation  scheme  is  identical  to  the  Contact  Analog  Grid  with  Tiles  except  the 
grid  is  missing. 

Posttops  — 


The  Posttops  format  consists  of  lighting  each  sample  point  in  the  DTED  database  at  the 
appropriate  elevation  in  the  perspective  view  volume. 
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Emergent  Detail — 

An  approach  to  cueing  the  pilot  to  critical  altitude  changes  (i.e.,  penetration  of  the 
“harddeck”)  is  change  formats.  The  use  of  emergent  detail  is  intended  to  cue  the  pilot  to 
a  change  in  situation  without  requiring  a  great  deal  of  cognitive  processing. 

The  use  of  emergent  detail  to  cue  terrain  proximity  is  not  new  (Reardon  and  Warren, 
1989),  but  the  application  to  an  HMD  would  be  unique.  An  example  strategy  for  the  use 
of  emergent  detail  would  be  to  present  Posttops  when  above  2,000  feet  AGL.  The 
Posttops  would  change  to  the  Contact  Analog  Grid  below  2,0()0  feet,  and  Tiles  would  be 
added  to  the  Grid  below  500  feet  AGL. 


Above  2,000  ft  AGL  Below  2,000  ft  AGL  Below  500  ft  AGL 


PILOT-VEHICLE  INTEGRATION 

Acceptance  of  the  display,  in  terms  of  subjective  pilot  opinion,  is  pivotal  for 
implementation  of  STl  in  helmet-mounted  displays  in  an  operational  environment. 
Display  factors  that  will  affect  pilot  acceptance  of  the  display  include  Depth  Cueing, 
Sampling  Density,  View  Volume,  and  Anti-Aliasing.  All  of  these  factors  will  have  an 
impact  on  processing  requirements  and  graphics  throughput  which  in  turn  impact  real¬ 
time  performance  of  the  display. 

Depth  Cueing 

By  varying  the  intensity  of  STI  elements  (distant  portions  of  the  terrain  are  shown 
dimmer)  Ae  real-world  phenomenon  of  blurring  of  distant  objects  can  be  achieved.  It  is 
also  a  means  by  which  teirain  entering  the  display  view  volume  can  “gracefully”  come 
into  view,  as  opposed  to  the  sudden  appearance  of  a  new  STI  elements.  Depth  cueing 
requires  that  a  light  source  and  appropriate  shading  algorithms  are  executed. 

Sampling  Density 

The  data  base  supplying  terrain  information,  U.S.  Defense  Mapping  Agency’s  Digital 
Terrain  Elevation  Data  (DTED),  provides  terrain  elevation  in  100  meter  increments. 
Therefore  the  greatest  resolution  available  to  STI  is  100  meters.  Sampling  density  has  a 
direct  effect  on  speed  of  graphics  processing,  the  higher  the  density  sampled  the  slower 
the  graphics  processing  (more  data  slows  the  processing). 
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View  Volume 

The  “distance”  from  the  closest  terrain  depiction  to  the  STI  horizon  is  called  the  view 
volume  of  the  display.  View  volume  can  be  selected,  ranging  from  1  to  6  nautical  miles. 
View  volume  has  a  direct  effect  on  speed  of  graphics  processing,  the  greater  the  view 
volume  the  slower  the  graphics  processing  (more  data  slows  the  processing). 

Anti-Alisaing 

There  are  a  number  of  subjective  factors  that  contribute  to  the  perception  of  display 
quality.  A  key  element  is  the  “smooth”  rotation  transition  of  a  line  from  horizontal  to 
vertical.  Aliasing  occurs  when  a  line  becomes  “jagged”  during  this  rotation.  There  are 
different  methods  by  which  anti-aliasing  can  be  accomplished,  including  adding  separate, 
dedicated,  processing  hardware. 

Real-Time  Operation  (Update  Rate) 

During  preliminary  format  development  it  became  clear  that  maintaining  an  update  rate 
of  at  least  15hz  is  difficult  when  the  STI  format  was  rendered  from  the  highest  sample 
density  (1(X)  meter  spacing)  with  a  large  view  volume  (6  miles).  In  the  current 
implementation  sample  density  can  be  set  to  one  of  the  following  settings  (1(X),  2(X),  4(X), 
or  SCio  meter).  The  view  volume  can  vary,  in  tenth  of  a  mile  increments  between  1  and  6 
miles. 

One  of  the  key  elements  in  the  initial  tests  in  the  PVI  development  station  at  General 
Dynamics  will  be  to  determine  the  lowest  acceptable  update  rate  for  the  display. 

RECOMMENDED  APPROACH 

The  Honeywell/General  Dynamics  team  will  conduct  evaluations  of  the  Synthetic  Terrain 
Imagery  formats  in  both  part-task  and  full  mission  simulation.  Operationally  oriented 
mission  scenarios  will  be  flown  under  varied  terrain  and  visibility  conditions  to  determine 
if  STI  aids  the  pilot  with  spatial  orientation.  Mechanization’s  for  controlling  STI 
viewability/intensity  will  iso  be  investigated. 

PART-TASK  SIMULATION 

In  an  attempt  to  eliminate  unnecessary  test  conditions  for  the  actual  evaluation.  General 
Dynamics  will  utilize  in-house  test  pilots  and  former  F-16  pilots  to  determine  which  STI 
techniques  have  high  potential.  The  following  Table  is  the  initial  “cut”  at  the  relative 
merits  and  disadvantages  to  each  approach. 
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Pro 


Con 


bll  rUMMAI^ 

Ridgelines 

Previous  flight  test 
experience  Quiet  Knight 

Aircraft  centered  "SQUIRM" 

Optical 

Expansion 

Gradieni 

Looks  like  the  OEG  on  an 
analog  Attitude  Direction 
Indicator  (ADI) 

From  altitude,  with  -90*. 
the  splay  lines  provide 
minimal  info 

Contact 

Analog 

Grid 

Intuitive 

Grid  &  Tiles 

Terrain  features  stand  out 

Can  be  a  "virtual"  VR  world 

May  be  too  cluttered  for 
un-aided  target  acquisition 

Tiles 

Tile  orientation  alone  may 
be  adequate  for  terrain  SA 

Obscures  terrain  information 
with  low  sampling  density 

Posttops 

Visually  least  intrusive 

Terrain  features  hard  to 
discern 

Relative  Merits  ofSTI  Formats 

For  the  actual  evaluation,  the  F-16  SPO,  as  well  as  selected  active  duty  F-16  pilots  will  be 
exposed  to  the  high  potential  STI  formats  in  a  part-task  simulation  evaluation. 

FULL-MISSION  SIMULATION 

The  best  techniques  will  be  transferred  to  the  dome  where  they  can  be  evaluated  utilizing 
combat  mission  profiles.  Each  participating  pilot  will  evaluate  the  STI  techniques.  Each 
mission  will  be  verbally  debriefed  and  a  questionnaire  completed.  Additionally, 
objective  mission  data  will  be  collected  and  compared  to  the  subjective  data  obtained 
from  the  questionnaires.  Conclusions  and  recommendations  will  then  be  derived  based 
on  the  objective  and  subjective  data  collected. 


B-12 


Selected  Readings 

Biberman,  L.  M.  and  Alluisi,  E.  A.  (1992).  Pilot  errors  involving  head-up  displays 

(HUDs),  helmet-mounted  displays  (HMDs),  and  night  vision  goggles  (NVGs). 
IDA  Paper  P-2638.  Institute  for  Defense  Analyses,  Alexandria,  VA. 

Haber,  R.N.  (1987).  Why  low-flying  fighter  planes  crash:  Perceptual  and  attentional 
factors  in  collisions  with  the  ground.  Human  Factors,  29(5),  519-532. 

Hale,  S.  and  Piccione,  D.  (1989).  Pilot  assessment  of  the  AH-64  helmet  mounted  display 
system.  Proceedings  of  the  Fifth  International  Aviation  Psychology  Symposium, 
pages  307-312. 

Ikeda,  M.  and  Takeuchi,  T.  (1975).  Influence  of  foveal  load  on  the  functional  visual 
field.  Perception  &  Psychophysics,  18(4),  255-260. 

Jarvi,  D.  W.  (1981).  Investigation  of  spatial  disorientation  of  F-15  Eagle  pilots. 

Technical  Report  ASD-TR-8I -5016,  Directorate  of  Equipment  Engineering,  Air 
Force  Systems  Command,  Wright-Patterson  AFB,  OH. 

Malcolm,  R.  (1984).  Pilot  disorientation  and  the  use  of  a  peripheral  vision  display.  In: 
Aviation,  Space,  and  Environmental  Medicine,  Aerospace  Medical  Association, 
Washington,  D.C. 

Newman,  R.  L.  (1987).  Responses  to  Roscoe,  “The  trouble  with  HUDs  and  HMD.” 
Human  Factors  Society  Bulletin,  Vol  30.. 

Poppen,  J.  R.  (1936).  Equilibratory  functions  in  instrument  flying.  The  Journal  of 
Aviation  Medicine,  7,  Aero  Medical  Association  of  the  United  States. 

Reardon,  K.  .A.  and  Warren,  R.  (1989).  Effect  of  emergent  detail  on  descent-rate 

estimations  in  flight  simulators.  Proceedings  of  the  Fifth  International  Aviation 
Psychology  Symposium,  pages  714-719. 

Roscoe,  S.  N.  (1987).  The  trouble  with  HUDs  and  HMDs.  Human  Factors  Society 
Bulletin,  Vol.  30. 

Roscoe,  S.  N.  (1987).  The  trouble  with  virtual  images  revisited.  Human  Factors  Society 
Bulletin.  Vol.  30. 

Weinstein,  L.  F.  and  Wickens,  C.  D.  (1992).  Use  of  Nontraditional  Flight  Displays  for 
the  Reduction  of  Central  Visual  Overload  in  the  Cockpit  The  International 
Journal  of  Aviation  Psychology,  2(2),  121-142. 

Weintraub,  D.  J.  (1987).  HUDs,  HMDs,  and  common  sense:  Polishing  virtual  images. 
Human  Factors  Society  Bulletin,  Vol.  30. 

Williams,  L.  J.  (1982).  Cognitive  load  and  the  functional  field  of  view.  Human  Factors, 
24(6),  683-692. 

Williams,  L.  J.  (1985).  Tunnel  vision  induced  by  a  foveal  load  manipulation.  Human 
Factors,  27(2),  221-227. 


B-13 


Addendum  to  Appendix  B 

(cited  from  Jarvi,  1981) 

VISUALLY  INDUCED  SPATIAL  DISORIENTATION 

Orientation  from  the  external  scene  during  flight  depends  upon  perception  of  complex 
and  continually  changing  patterns  of  visud  stimuli.  The  validity  and  accuracy  of  both  the 
perception  and  the  interpretation  of  these  cues  is  a  function  of  the  aviator’s  experience 
and  training.  Attitude  is  judged  by  reference  to  the  horizon  or  when  nearer  the  ground,  by 
the  verticals  of  buildings,  masts,  and  trees.  Distance  and  depth  are  determined  principally 
by  monocular  cues  such  as  parallactic  displacement,  aerial  perspective,  apparent  size,  and 
by  changes  in  both  detail  and  color  with  distance  (Benson,  1965). 

Unfortunately,  outside  visual  references  are  often  reduced  by  smoke,  haze,  fog,  inclement 
weather,  or  darkness.  In  such  situations  the  pilot’s  interpretation  of  visual  cues  becomes 
more  difficult,  illusory  visual  information  may  occur,  and  visual  phenomena  themselves 
may  contribute  to  disorientation.  Examples  of  these  types  of  spatial  disorientation 
(adapted  from  Peters,  1968)  are  listed  below: 

(a)  Autokinesis.  This  illusion  consists  of  an  apparent  motion  of  isolated  lights 
viewed  in  a  meager  visual  framework.  If  an  isolated  light  is  viewed  continually  in  Ae 
dark,  it  will  appear  to  wander  about  at  random  over  a  small  area.  The  apparent  motion 
may  extend  as  much  as  15  degrees  and  is  indistinguishable  from  real  motion.  Pilots  have 
reported  attempts  to  join  up  with  a  formation  of  stars,  buoys,  lights  on  bridges,  and  street 
lights  which  appeared  to  be  moving  and  were  interpreted  as  other  aircraft. 

(b)  Fascination.  This  is  a  condition  in  which  the  pilot  fails  to  respond 
adequately  to  a  clearly  defined  stimulus  situation  in  spite  of  the  fact  that  all  of  the 
necessary  cues  are  present  for  a  proper  response,  and  the  correct  procedure  is  well  known 
to  him. 

(c)  Target  Hypnosis.  Target  hypnosis  is  a  form  of  fascination  and  is 
characterized  by  a  pilot  becoming  so  intent  on  destroying  the  target  during  an  attack  that 
he  fails  to  pull  up  in  time  to  avoid  striking  the  ground,  usually  with  fatal  consequences. 

(d)  Illusory  Effects  Due  to  Inadequate  Stimuli.  Restriction  of  the  visual  field 
by  smoke,  dust,  haze,  fog,  rain,  or  darkness  can  produce  gross  discrep^cies  between 
physical  entities  and  their  appearance  as  perceived  by  the  pilot.  The  pilot’s  attempt  to 
restructure  the  physical  entity  from  his  meager  perception  of  it  may  result  in  a  false 
identification  and  consequent  disorientation. 

(e)  Improper  Grouping  of  Lights  at  Night.  The  tendency  to  group  items  in  he 
perceptual  field  can  contribute  to  illusory  effects.  A  small  cluster  of  isolated  lights  on  the 
ground  on  a  dark  night  with  a  high  overcast  may  be  interpreted  as  the  lights  of  a 
formation  flight. 

(f)  Illusions  of  Relative  Motion.  Experience  of  illusions  of  relative  motion  are 
numerous.  To  an  observer  in  a  fast  aircraft  crossing  the  path  of  a  much  slower  aircraft  at 
a  different  altitude,  the  slower  aircraft  appears  to  be  fl^g  sideways  and  backwards. 
Illusions  of  relative  motion  can  be  especially  provocative  and  potentially  hazardous 
during  formation  flights  at  high  altitude  or  at  night  when  cues  to  forward  speed  are 
absent. 
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(g)  Illusory  Horizons.  The  primary  cue  to  the  vertical  is  the  visible  horizon; 
using  this  cue  the  pilot  can  orient  his  aircraft  properly  and  with  great  precision.  Under 
conditions  of  restricted  visibility  the  horizon  may  become  obscure  or  occulted.  Under 
these  conditions  the  pilot  may  rely  on  some  other  indicator  which  he  believes  to  represent 
the  horizontal.  Under  certain  other  conditions  and  in  perfectly  clear  weather  the  pilot 
may  orient  his  aircraft  improperly  despite  using  the  visible  horizon  as  a  reference. 

Various  types  of  disorientation  may  be  produced  by  reliance  on  fictitious  horizons  (e.g., 
tilted  cloud  banks;  depressed  horizons  due  to  high  altitude  flight;  confusion  between  city 
lights  and  stars). 
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